gh-91962: Fix hstrerror detection issues on Solaris

[kulikjak]

Configure only checks whether inet_aton needs -lresolv but it also needs to check hstrerror (because on Solaris, inet_aton no longer needs -lresolv, but hstrerror does).

Issue #91962 has more detailed explanation.

• Issue: Issues building Python main on Solaris #91962

[encukou]

LGTM!
Let's merge after alpha 4 is cut, so if something's wrong we don't block the release process.

[erlend-aasland]

I'm not sure if this is the correct fix; please hold on merging it.

[kulikjak]

I tested it on Solaris and it seems to work as expected, but I won't pretend that I am an autotools expert and it's perfectly possible that I overlooked something.

[erlend-aasland]

I tested it on Solaris and it seems to work as expected, but I won't pretend that I am an autotools expert and it's perfectly possible that I overlooked something.

There is an existing hstrerror check. If it is incorrect, should we not fix that instead of adding a new check?

[kulikjak]

I presume you mean the PY_CHECK_NETDB_FUNC([hstrerror]) line? That one seems to check whether hstrerror is available, not whether it needs additional libraries to link. I guess I can shuffle the code a little and move the -lresolv check near the corresponding PY_CHECK_NETDB_FUNC but that would mean more extensive changes.

That said, there was indeed a slight issue with the detection - it wouldn't work correctly on a system where hstrerror needs -lresolv and inet_aton doesn't exist (although I don't think that is the case anywhere...)

Holding

[encukou]

@erlend-aasland, does this look good?

[kulikjak]

I just finished working on an updated version of the check - the old one stopped working at some point, because extensions are no longer using LIBS it seems.

This one keeps AC_CHECK_LIB and just adds another check for hstrerror.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 3cfc710 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

I plan to merge this tomorrow if there are no objections.

[erlend-aasland]

I plan to merge this tomorrow if there are no objections.

With this PR, HAVE_LIBRESOLV will never be defined in pyconfig.h anymore. I don't think that will be a problem; just a heads-up. We don't use HAVE_LIBRESOLV in our code base.

[encukou]

My gut feeling is that the general idea is OK: HAVE_LIBRESOLV means that we have -lresolv in the flags, so if we drop -lresolv for CPython itself, HAVE_LIBRESOLV should go too.

Alas, if you link socket statically, you get -lresolv but not HAVE_LIBRESOLV. I don't think we can handle that well with current tooling?

[erlend-aasland]

Alas, if you link socket statically, you get -lresolv but not HAVE_LIBRESOLV. I don't think we can handle that well with current tooling?

You can just modify the action-if-true block to explicitly define HAVE_LIBRESOLV (it was implicitly defined before, since the action-if-true block was empty).

[kulikjak]

I can do so, but is it really necessary considering that HAVE_LIBRESOLV is currently not used anywhere? It can always be easily added later once it becomes necessary.

[erlend-aasland]

I can do so, but is it really necessary considering that HAVE_LIBRESOLV is currently not used anywhere? It can always be easily added later once it becomes necessary.

It is also exported in Python.h via pyconfig.h, but IMHO it is not needed; I'm fine with the patch as it is (which is also why I approved it).

[kulikjak]

Thank you both very much!