[Date Prev][Date Next]
Re: 2.0-alpha and Solaris 7
I committed some changes which should resolve these issues.
- backed out dir.mk changes which broke 'make veryclean'
- moved res_search detection from out behind --enable-dns
- used link test for inet_aton() detection
Please test and provide feedback.
At 02:31 AM 8/16/99 +1000, David J N Begley wrote:
>On Sat, 14 Aug 1999, David J N Begley wrote:
>> Prima facie, this looks cool. Environ is Sol7/SPARC and gcc 2.8.1. I'd
>> better wait for the release of "alpha2" before pushing this too much harder,
>> to ensure that I'm chasing a genuine problem as opposed to one caused by
>> mixing 'n' matching revs.
>I managed to build CVS and pull down a copy of OpenLDAP-devel. As before,
>"configure" now works for POSIX threads. The "inet_aton" issue hasn't gone
>- configure claims inet_aton is present, but it only appears to compile
> a test programme, it doesn't actually *link* anything (at which point
> it would fail)
>- AC_LIBS needs "-lresolv" added for inet_aton to be included, as used by:
> which in turn then affects everything linked with these libraries:
>- currently AC_LIBS on Sol7 contains "-lgen -lnsl -lsocket", so I was
> thinking of modifying the configure.in tests (circa line 625):
> AC_CHECK_LIB(socket, main)
> AC_CHECK_LIB(nsl, main)
> AC_CHECK_LIB(gen, main)
> AC_CHECK_LIB(resolv, inet_aton)
> the issue being, of course, that these tests are meant to find socket();
> given that socket() is in -lsocket and not -lgen or -lnsl (yet they're
> included anyway), it may not be such a bad thing after all...
> The "main" check in -lsocket, -lgen and -lnsl appear to match the symbol
> "_thr_main" in each library - there's no equiv in -lresolv so a "main"
> check there wouldn't work
> Alternatively, could the current check for inet_aton actually do a link
> in addition to compile operation (which would fail), followed by a check
> for inet_aton in -lresolv (compile/link would pass, add -lresolv to
>- "make distclean" doesn't remove these files:
>After all this, "make test" still results in a core dump anyway so now I need
>to dig a little further...