On Wed, Jan 11, 2006 at 04:22:05PM +1100, Brian May wrote:

> I don't see any evidence this is or is not Heimdal's fault yet. Nor am I
> sure what Sebastian meant. I think he means "configure running on hppa
> finds gss_display_status; but configure running on mips/mepsel doesn't"
> and not "I checked the libraries manually and found gss_display_status
> on hppa but not on mips/mipsel".

> The most likely suspect would appear to be the configure script in
> netatalk is failing to detect the library correctly. Especially as it
> appears to be only mips/mipsel that has this problem.

> Can somebody with access to mips and/or HPPA please confirm if -lgssapi
> has the gss_acquire_cred symbol on both platforms?

You're a Debian developer.  You have access to systems of each architecture. 
You can also check for the symbol's presence using objdump and a public
mirror.

> e.g. by compiling the following program:

> --- cut ---
> main() {
>         gss_acquire_cred();
> }
> --- cut ---

> with

> gcc -lgssapi test.c

This is also the wrong test, because it's not gss_acquire_cred detection
that fails.  The configure script is failing to detect *libgssapi* on
mips/el:

checking for gss_display_status in -lgssapi... no
checking for gss_display_status in -lgssapi_krb5... no

So there's no -lgssapi being added to $LIBS, so naturally looking for
gss_display_status also fails afterwards.

Anyway, the reason appears to be this:

[EMAIL PROTECTED]:~$ LD_LIBRARY_PATH=~/usr/lib/ ldd -d -r 
~/usr/lib/libgssapi.so.4
        libkrb5.so.17 => /home/vorlon/usr/lib/libkrb5.so.17 (0x2ab04000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x2aba4000)
        libasn1.so.6 => /home/vorlon/usr/lib/libasn1.so.6 (0x2ad4c000)
        libroken.so.16 => /home/vorlon/usr/lib/libroken.so.16 (0x2adc4000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x2ae1c000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x2ae8c000)
        libc.so.6 => /lib/libc.so.6 (0x2aee0000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x2b07c000)
        libdl.so.2 => /lib/libdl.so.2 (0x2b0c0000)
        libz.so.1 => /usr/lib/libz.so.1 (0x2b104000)
        libdb-4.2.so => /usr/lib/libdb-4.2.so (0x2b158000)
        /lib/ld.so.1 (0x55550000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2b290000)
undefined symbol: pthread_setspecific (/home/vorlon/usr/lib/libgssapi.so.4)
undefined symbol: pthread_key_create (/home/vorlon/usr/lib/libgssapi.so.4)
undefined symbol: pthread_getspecific (/home/vorlon/usr/lib/libgssapi.so.4)
[EMAIL PROTECTED]:~$

That looks pretty clearly like a heimdal bug to me.

On other architectures where netatalk builds successfully, libgssapi.so.4 is
linked to libpthread.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply via email to