Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Package: krb5 Version; 1.4.3-2 Severity: important Hi, thanks for applying the POSIX portability patch. However, it has now turned up that there is another problem with pthread support, I am sorry we did not catch this earlier: Automatic build of krb5_1.4.3-2 on beethoven by sbuild/hurd-i386 69 Build started at 20051201-1731 ** [...] ** Using build dependencies supplied by package: Build-Depends: libncurses5-dev, docbook-to-man, debhelper (= 4.1.16), byacc | bison, comerr-dev (= 2.0-1.33-2), ss-dev, texinfo ( 4.1) [...] Checking correctness of source dependencies... Toolchain package versions: libc0.3-dev_2.3.5-6 gcc-4.0_4.0.2-4 g++-4.0_4.0.2-4 binutils_2.16.1-2 libstdc++6-4.0-dev_4.0.2-4 libstdc++6_4.0.2-4 -- dpkg-source: extracting krb5 in krb5-1.4.3 dpkg-source: unpacking krb5_1.4.3.orig.tar.gz dpkg-source: applying /org/buildd/build/krb5_1.4.3-2.diff.gz dpkg-buildpackage: source package is krb5 dpkg-buildpackage: source version is 1.4.3-2 dpkg-buildpackage: host architecture hurd-i386 [...] debian/rules build dh_testdir mkdir build find src -name configure -print | xargs touch find src \( -name \*hin -o -name \*.h.in -o -name \*.stmp \) -print \ | xargs touch cd build ../src/configure --prefix=/usr --enable-shared \ --with-system-et --with-system-ss --enable-fakeka \ CFLAGS=-g -O2 -D_REENTRANT --localstatedir=/etc \ --mandir=/usr/share/man --without-tcl configure: creating cache ./config.cache [...] configure: enabling thread support checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... no checking whether pthreads work with -mthreads... no checking for the pthreads library -lpthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for cc_r... gcc configure: PTHREAD_CC = gcc configure: PTHREAD_CFLAGS = configure: PTHREAD_LIBS = -lpthread checking for pthread_once... no checking for pthread_mutexattr_setrobust_np... no checking for pthread_rwlock_init... no configure: rechecking with PTHREAD_... options checking for pthread_mutexattr_setrobust_np in -lc... no checking for pthread_rwlock_init in -lc... yes [...] cd build /usr/bin/make all [...] making all in lib/rpc/unit-test... make[4]: Entering directory `/build/buildd/krb5-1.4.3/build/lib/rpc/unit-test' gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DKRB5_KRB4_COMPAT=1 -DHAVE_BT_RSEQ=1 -DKRB5_PRIVATE=1 -DKRB5_DEPRECATED=1 -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_LIBRESOLV=1 -DHAVE_RES_NINIT=1 -DHAVE_RES_NCLOSE=1 -DHAVE_RES_NSEARCH=1 -DHAVE_DN_SKIPNAME=1 -DHAVE_RES_SEARCH=1 -DHAVE_PRAGMA_WEAK_REF=1 -DDELAY_INITIALIZER=1 -DCONSTRUCTOR_ATTR_WORKS=1 -DDESTRUCTOR_ATTR_WORKS=1 -DENABLE_THREADS=1 -DHAVE_PTHREAD=1 -DHAVE_PTHREAD_RWLOCK_INIT_IN_THREAD_LIB=1 -DHAVE_REGCOMP=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DPOSIX_SIGNALS=1 -I../../../include -I../../../../src/lib/rpc/unit-test/../../../include -I../../../include/krb5 -I../../../../src/lib/rpc/unit-test/../../../include/krb5 -I. -g -O2 -D_REENTRANT -c ../../../../src/lib/rpc/unit-test/client.c gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DKRB5_KRB4_COMPAT=1 -DHAVE_BT_RSEQ=1 -DKRB5_PRIVATE=1 -DKRB5_DEPRECATED=1 -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_LIBRESOLV=1 -DHAVE_RES_NINIT=1 -DHAVE_RES_NCLOSE=1 -DHAVE_RES_NSEARCH=1 -DHAVE_DN_SKIPNAME=1 -DHAVE_RES_SEARCH=1 -DHAVE_PRAGMA_WEAK_REF=1 -DDELAY_INITIALIZER=1 -DCONSTRUCTOR_ATTR_WORKS=1 -DDESTRUCTOR_ATTR_WORKS=1 -DENABLE_THREADS=1 -DHAVE_PTHREAD=1 -DHAVE_PTHREAD_RWLOCK_INIT_IN_THREAD_LIB=1 -DHAVE_REGCOMP=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DPOSIX_SIGNALS=1 -I../../../include -I../../../../src/lib/rpc/unit-test/../../../include -I../../../include/krb5 -I../../../../src/lib/rpc/unit-test/../../../include/krb5 -I. -g -O2 -D_REENTRANT -c ../../../../src/lib/rpc/unit-test/rpc_test_clnt.c gcc -L../../../lib -g -O2 -D_REENTRANT -o client client.o rpc_test_clnt.o \ -lgssrpc -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv ../../../lib/libgssapi_krb5.so:
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
does your platform support weak symbols? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
On Thu, Dec 01, 2005 at 05:51:16PM +0100, Michael Banck wrote: I am not sure whether all the Makefile.in's should be modified to have $PTHREAD_LIBS added to the link lines in case the library uses pthread functions (or their k5_ equivalents) or whether we could get away with some hack like [EMAIL PROTECTED]@ @PTHREAD_LIBS@ in config/pre.in, or something system-specific along the aix/hp-ux cases in configure.in, so I am not submitting any patches at this point. As a data point, I successfully built the package by adding @PTHREAD_LIBS@ to the LIBS= line in src/config/pre.in. However, this also means that ldd/objdump shows libpthread dependencies on all the binaries I looked at during a quick check. cheers, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
On Thu, Dec 01, 2005 at 01:02:29PM -0500, Sam Hartman wrote: does your platform support weak symbols? Yes, it does. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
On Thu, Dec 01, 2005 at 07:15:06PM +0100, Michael Banck wrote: On Thu, Dec 01, 2005 at 01:02:29PM -0500, Sam Hartman wrote: does your platform support weak symbols? Yes, it does. OK, I think we figured out why this is: 19:11 Jeroen given that krb is a library, it probably supports programs which are multithreaded 19:11 Jeroen so it doesn't have to use pthreads 19:11 Jeroen only when pthreads is there, it has to do proper locking 19:11 Jeroen so it declares the symbols weak 19:11 Jeroen and checks whether they are available 19:12 Jeroen but because pthread_mutex_lock is an inline function calling _pthread_mutex_lock 19:12 Jeroen and krb doesn't know about that 19:13 Jeroen there is a non-weak reference to _pthread_mutex_lock I guess one option would be to patch krb5 to add weak pragmas for _pthread_mutex_lock et al. The other option would be to change libpthread to not have these inline functions. I will talk to the Hurd maintainers about this, do you have an opinion whether a change in krb5 (at least for Debian) is feasable in the meantime? cheers, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Michael Banck [EMAIL PROTECTED] writes: I guess one option would be to patch krb5 to add weak pragmas for _pthread_mutex_lock et al. The other option would be to change libpthread to not have these inline functions. I will talk to the Hurd maintainers about this, do you have an opinion whether a change in krb5 (at least for Debian) is feasable in the meantime? Given that we're already patching specific to Debian for Hurd portability, I think it's reasonable to add additional weak pragmas for the Hurd if you can provide a patch that only does this on Hurd (I don't know which pragmas are needed). However, I don't think it's the right long-term solution for applications to have to know about this sort of internal implementation detail, so ideally I think it should be fixed in libpthread in the long term. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Michael == Michael Banck [EMAIL PROTECTED] writes: Michael On Thu, Dec 01, 2005 at 05:51:16PM +0100, Michael Banck Michael wrote: I am not sure whether all the Makefile.in's should be modified to have $PTHREAD_LIBS added to the link lines in case the library uses pthread functions (or their k5_ equivalents) or whether we could get away with some hack like [EMAIL PROTECTED]@ @PTHREAD_LIBS@ in config/pre.in, or something system-specific along the aix/hp-ux cases in configure.in, so I am not submitting any patches at this point. Michael As a data point, I successfully built the package by Michael adding @PTHREAD_LIBS@ to the LIBS= line in Michael src/config/pre.in. However, this also means that Michael ldd/objdump shows libpthread dependencies on all the Michael binaries I looked at during a quick check. Right and that would be very bad for Debian. You need to figure out why there are not weak references. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Michael == Michael Banck [EMAIL PROTECTED] writes: Michael On Thu, Dec 01, 2005 at 01:02:29PM -0500, Sam Hartman Michael wrote: does your platform support weak symbols? Michael Yes, it does. OK. those references should be weak but were not for some reason. I'm not going to be able to debug this because I don't have time and don't have a hurd machine. I'd recommend looking at why the symbols are not being considered weak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
tags 341608 +patch thanks On Thu, Dec 01, 2005 at 10:49:11AM -0800, Russ Allbery wrote: Michael Banck [EMAIL PROTECTED] writes: I guess one option would be to patch krb5 to add weak pragmas for _pthread_mutex_lock et al. The other option would be to change libpthread to not have these inline functions. I will talk to the Hurd maintainers about this, do you have an opinion whether a change in krb5 (at least for Debian) is feasable in the meantime? Given that we're already patching specific to Debian for Hurd portability, I think it's reasonable to add additional weak pragmas for the Hurd if you can provide a patch that only does this on Hurd (I don't know which pragmas are needed). The attached patch makes the build go fine. However, I don't think it's the right long-term solution for applications to have to know about this sort of internal implementation detail, so ideally I think it should be fixed in libpthread in the long term. Agreed. We already had this issue with libstdc++, and will need to find a more general solution soon. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html --- include/k5-thread.h.orig2005-12-01 22:12:36.0 +0100 +++ include/k5-thread.h 2005-12-01 22:05:37.0 +0100 @@ -375,6 +375,12 @@ # pragma weak pthread_mutex_init # pragma weak pthread_self # pragma weak pthread_equal +# if __GNU__ +# pragma weak _pthread_mutex_lock +# pragma weak _pthread_mutex_unlock +# pragma weak _pthread_mutex_destroy +# pragma weak _pthread_mutex_init +# endif /* __GNU__ */ # ifdef HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP_IN_THREAD_LIB # pragma weak pthread_mutexattr_setrobust_np # endif
