Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
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 (0x2aee)
libcom_err.so.2 = /lib/libcom_err.so.2 (0x2b07c000)
libdl.so.2 = /lib/libdl.so.2 (0x2b0c)
libz.so.1 = /usr/lib/libz.so.1 (0x2b104000)
libdb-4.2.so = /usr/lib/libdb-4.2.so (0x2b158000)
/lib/ld.so.1 (0x)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b29)
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/
signature.asc
Description: Digital signature
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve On other architectures where netatalk builds successfully, Steve libgssapi.so.4 is linked to libpthread. Thanks for your investigations. So are you saying Heimdal is meant to link libgssapi with -lpthread, but doesn't for some reason on MIPS? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
On Wed, Jan 11, 2006 at 12:52:00AM -0800, Steve Langasek wrote: On Wed, Jan 11, 2006 at 04:22:05PM +1100, Brian May wrote: 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 (0x2aee) libcom_err.so.2 = /lib/libcom_err.so.2 (0x2b07c000) libdl.so.2 = /lib/libdl.so.2 (0x2b0c) libz.so.1 = /usr/lib/libz.so.1 (0x2b104000) libdb-4.2.so = /usr/lib/libdb-4.2.so (0x2b158000) /lib/ld.so.1 (0x) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b29) 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. And it looks like it should be on mips* as well: /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o libgssapi.la -rpath /usr/lib -version-info 4:0:0 asn1_ContextFlags.lo asn1_MechType.lo asn1_MechTypeList.lo asn1_NegotiationToken.lo asn1_NegTokenInit.lo asn1_NegTokenTarg.lo 8003.lo accept_sec_context.lo acquire_cred.lo add_cred.lo add_oid_set_member.lo arcfour.lo canonicalize_name.lo ccache_name.lo cfx.lo compare_name.lo compat.lo context_time.lo copy_ccache.lo create_emtpy_oid_set.lo decapsulate.lo delete_sec_context.lo display_name.lo display_status.lo duplicate_name.lo encapsulate.lo export_sec_context.lo export_name.lo external.lo get_mic.lo import_name.lo import_sec_context.lo indicate_mechs.lo init.lo init_sec_context.lo inquire_context.lo inquire_cred.lo inquire_cred_by_mech.lo inquire_mechs_for_name.lo inquire_names_for_mech.lo release_buffer.lo release_cred.lo release_name.lo release_oid_set.lo sequence.lo process_context_token.lo ticket_flags.lo test_oid_set_member.lo unwrap.lo v1.lo verify_mic.lo wrap.lo address_to_krb5addr.lo ../krb5/libkrb5.la -lcrypto ../asn1/libasn1.la ../../lib/vers/libvers.la ../../lib/roken/libroken.la -lcrypt -lresolv -pthread gcc -shared .libs/asn1_ContextFlags.o .libs/asn1_MechType.o .libs/asn1_MechTypeList.o .libs/asn1_NegotiationToken.o .libs/asn1_NegTokenInit.o .libs/asn1_NegTokenTarg.o .libs/8003.o .libs/accept_sec_context.o .libs/acquire_cred.o .libs/add_cred.o .libs/add_oid_set_member.o .libs/arcfour.o .libs/canonicalize_name.o .libs/ccache_name.o .libs/cfx.o .libs/compare_name.o .libs/compat.o .libs/context_time.o .libs/copy_ccache.o .libs/create_emtpy_oid_set.o .libs/decapsulate.o .libs/delete_sec_context.o .libs/display_name.o .libs/display_status.o .libs/duplicate_name.o .libs/encapsulate.o .libs/export_sec_context.o .libs/export_name.o .libs/external.o .libs/get_mic.o .libs/import_name.o .libs/import_sec_context.o .libs/indicate_mechs.o .libs/init.o .libs/init_sec_context.o .libs/inquire_context.o .libs/inquire_cred.o .libs/inquire_cred_by_mech.o .libs/inquire_mechs_for_name.o .libs/inquire_names_for_mech.o .libs/release_buffer.o .libs/release_cred.o .libs/release_name.o .libs/release_oid_set.o .libs/sequence.o .libs/process_context_token.o .libs/ticket_flags.o .libs/test_oid_set_member.o .libs/unwrap.o .libs/v1.o .libs/verify_mic.o .libs/wrap.o .libs/address_to_krb5addr.o -Wl,--whole-archive ../../lib/vers/.libs/libvers.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/build/buildd/heimdal-0.7.1/build-tree/heimdal-0.7.1/lib/krb5/.libs -Wl,--rpath -Wl,/build/buildd/heimdal-0.7.1/build-tree/heimdal-0.7.1/lib/asn1/.libs -Wl,--rpath -Wl,/build/buildd/heimdal-0.7.1/build-tree/heimdal-0.7.1/lib/roken/.libs ../krb5/.libs/libkrb5.so -lcrypto ../asn1/.libs/libasn1.so ../../lib/roken/.libs/libroken.so -lcrypt -lresolv -pthread -Wl,-soname -Wl,libgssapi.so.4 -o .libs/libgssapi.so.4.0.0 http://buildd.debian.org/fetch.php?pkg=heimdalarch=mipsver=0.7.1-2stamp=1135222570file=log Need some mips porter lovin' on this one, I think, to figure out why gcc
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
* Steve Langasek [EMAIL PROTECTED] [2006-01-11 01:11]: And it looks like it should be on mips* as well: ... Need some mips porter lovin' on this one, I think, to figure out why gcc -pthread gives a library that's not linked to libpthread. I think you have to use -lpthread, see #273671. Thiemo will know for sure. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
On Wed, Jan 11, 2006 at 10:37:31AM +, Martin Michlmayr wrote: * Steve Langasek [EMAIL PROTECTED] [2006-01-11 01:11]: And it looks like it should be on mips* as well: ... Need some mips porter lovin' on this one, I think, to figure out why gcc -pthread gives a library that's not linked to libpthread. I think you have to use -lpthread, see #273671. Thiemo will know for sure. Ok, so it seems we need -pthread -lpthreads to be fully correct when building a shared lib that depends on pthreads, as the behavior of -pthread varies by architecture. Thanks. Brian, can you make the necessary change to the heimdal package, or should I prepare a patch? -- 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/ signature.asc Description: Digital signature
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve Ok, so it seems we need -pthread -lpthreads to be fully Steve correct when building a shared lib that depends on Steve pthreads, as the behavior of -pthread varies by Steve architecture. Thanks. Steve Brian, can you make the necessary change to the heimdal Steve package, or should I prepare a patch? I might be wrong, but my understanding after a very quick glance at the other bug report was: a) you can't just hard code -pthread -lpthreads as on some platforms -pthread is correct. b) heimdal uses libtool (from sarge currently), and libtool should do the right thing? (perhaps sarge is not a sufficient version). Maybe I need to read the other bug report in more detail again. I might be confused. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
On Thu, Jan 12, 2006 at 12:48:38PM +1100, Brian May wrote: Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve Ok, so it seems we need -pthread -lpthreads to be fully Steve correct when building a shared lib that depends on Steve pthreads, as the behavior of -pthread varies by Steve architecture. Thanks. Steve Brian, can you make the necessary change to the heimdal Steve package, or should I prepare a patch? I might be wrong, but my understanding after a very quick glance at the other bug report was: a) you can't just hard code -pthread -lpthreads as on some platforms -pthread is correct. No, this is not the case for any Debian platforms. On some platforms, -pthread is sufficient *because* it implies -lpthreads; but in all cases, libgssapi needs to be linking against libpthreads because it uses symbols from it, therefore -pthread -lpthreads is at worst redundant and at best it's exactly what's needed. b) heimdal uses libtool (from sarge currently), and libtool should do the right thing? (perhaps sarge is not a sufficient version). What I read in the bug log is that libtool sometimes tries to be *clever*, and therefore gets things wrong. That's not the case here; libtool is simply passing the linker arguments through unmodified. I don't see any reason why we should expect libtool to second-guess gcc itself regarding the meaning of -pthread. -- 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/ signature.asc Description: Digital signature
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
For reference, here is the corresponding build log for the HPPA architecture [1]: [...] checking for gssapi.h... yes checking gssapi/gssapi_generic.h usability... no checking gssapi/gssapi_generic.h presence... no checking for gssapi/gssapi_generic.h... no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h presence... no checking for gssapi/gssapi.h... no checking gssapi/gssapi_krb5.h usability... no checking gssapi/gssapi_krb5.h presence... no checking for gssapi/gssapi_krb5.h... no checking for gss_display_status in -lgssapi... yes checking for gss_display_status in -lgssapi_krb5... no checking for gss_acquire_cred... yes [...] hppa finds both, gss_display_status in -lgssapi and gss_acquire_cred, while mips (and mipsel) finds neither. Both architectures used heimdal 0.7.1-2. - Sebastian [1] http://buildd.debian.org/fetch.php?pkg=netatalkver=2.0.3-3arch=hppastamp=1135921021file=logas=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
Hello,
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?
e.g. by compiling the following program:
--- cut ---
main() {
gss_acquire_cred();
}
--- cut ---
with
gcc -lgssapi test.c
Also the config.log file of the failed build would be very useful.
Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346346: netatalk_2.0.3-3 (mips*/unstable): FTBFS: checking for gss_acquire_cred... no
Package: netatalk Version: 2.0.3-3 Severity: serious The netatalk package is failing to build on mips and mipsel with the current heimdal packages. This may be a heimdal bug. [...] checking for gssapi.h... yes checking gssapi/gssapi_generic.h usability... no checking gssapi/gssapi_generic.h presence... no checking for gssapi/gssapi_generic.h... no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h presence... no checking for gssapi/gssapi.h... no checking gssapi/gssapi_krb5.h usability... no checking gssapi/gssapi_krb5.h presence... no checking for gssapi/gssapi_krb5.h... no checking for gss_display_status in -lgssapi... no checking for gss_display_status in -lgssapi_krb5... no checking for gss_acquire_cred... no configure: error: GSSAPI: required function gss_acquire_cred missing make: *** [config.status] Error 1 [...] Full build log can be found at http://buildd.debian.org/fetch.php?pkg=netatalkarch=mipsver=2.0.3-3stamp=1135888398file=log. -- 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/ signature.asc Description: Digital signature
