Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]

Hi Kostik,

On 06/07/2010, at 18:54 , Kostik Belousov wrote:

> You need to gather and show exact command that fails.

There's some a little more info in PR: ports/145769, although the "fix" that I suggest there is almost certainly a wrong turn (I nuked all reference to MD2_* from libhx509, there).  I can't easily recreate the problem, now that I've patched my copy of /usr/src/kerberos5/lib/libhx509/Makefile, but the fault seems to be fairly consistent in the configure script of any port configured to use GSSAPI, such as fetchmail or evolution-data-server.  From memory, the failing program is a one-line main() that calls MD2_Init(), and attempts to link it with a command line derived from `krb5-config --lib gssapi`.

> Shared object that references a symbol but does not record a dependency
> on the object providing the symbol is the bug in the build of that object
> (usually).

That is what /usr/lib/libhx509.so.10 seems to do (see the undefined refs to MD2_* with nm /usr/lib/libhx509.a, and see the lack of dependency on /lib/libcrypto.so.6 with ldd), and yet this hasn't been widely reported, I suspect, because it still seems to work in 8-STABLE.  Don't know why.

The exact command that fails, in summary, is:

get a 9-current system.
cd /usr/ports/mail/fetchmail (or /usr/ports/databases/evolution-data-server, but that has lots of other dependencies that might take a while to build)
make config # and tell it to enable GSSAPI (and NTLM) which isn't the default.
make
# watch the configure fail with a report of missing KRB5, but inspection of the configure.log will show that the real failure was a failure to link against the system-supplied shared libraries, specifically libhx509.so.

Repeat the process on an 8-STABLE system and see that the config and build proceeds successfully, despite the fact that libhx509.so.10 has undefined symbols for MD2_* just as on -current.

Please let me know if there's any other info that I can provide.

Cheers,

-- 
Andrew