Summary: | subversion ebuld is not aware of heimdal deps in libneon | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin Mokrejš <mmokrejs> |
Component: | Current packages | Assignee: | Paul de Vrieze (RETIRED) <pauldv> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Hloupy.Honza, jfostiguy, jradmacher, patrick, seemant, stefaan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Mokrejš
2005-12-07 08:14:56 UTC
I noticed this as well, not investigated it yet *** Bug 114226 has been marked as a duplicate of this bug. *** Not sure what this has to do with apache... Could you indicate where the heimdal dependency comes from. neon does not depend on heimdal, openssl doesn't depend on heimdal, and subversion doesn't depend on heimdal. Also could you print out the results of "ldd /usr/lib/libneon.so" and "grep dependency_libs /usr/lib/libneon.la". In any case it seems that neon is linked improperly, or has an improper .la file. Looking at this and the other package it seems that the neon build is broken. It links against heimdal/krb5 even when not instructed to. (It shouldn't with the current ebuild. Probably a useflag should be added to the ebuild). phylo ~ # ldd /usr/lib/libneon.so linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb7f2d000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7efd000) libdl.so.2 => /lib/libdl.so.2 (0xb7ef9000) libgssapi.so.4 => /usr/lib/libgssapi.so.4 (0xb7ee2000) libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0xb7e99000) libasn1.so.6 => /usr/lib/libasn1.so.6 (0xb7e68000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e64000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7d63000) libroken.so.16 => /usr/lib/libroken.so.16 (0xb7d52000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d25000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7d12000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7d00000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7cd3000) libc.so.6 => /lib/tls/libc.so.6 (0xb7bbf000) /lib/ld-linux.so.2 (0x80000000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7aeb000) phylo ~ # grep dependency_libs /usr/lib/libneon.la dependency_libs=' -lz -lssl -L/usr/lib /usr/lib/libgssapi.la /usr/lib/libkrb5.la -ldl /usr/lib/libasn1.la -lcom_err -lcrypto /usr/lib/libroken.la -ldb -lcrypt -lresolv -lpthread /usr/lib/libexpat.la' phylo ~ # phylo ~ # /usr/bin/krb5-config --libs -L/usr/lib -lkrb5 -lasn1 -lcom_err -lcrypto -lroken -lcrypt -lresolv -lpthread phylo ~ # /usr/bin/krb5-config --libs krb5 -L/usr/lib -lkrb5 -lasn1 -lcom_err -lcrypto -lroken -lcrypt -lresolv -lpthread phylo ~ # /usr/bin/krb5-config --libs gssapi -L/usr/lib -lgssapi -lkrb5 -lasn1 -lcom_err -lcrypto -lroken -lcrypt -lresolv -lpthread phylo ~ # phylo ~ # /usr/bin/krb5-config --cflags -I/usr/include/heimdal phylo ~ # What does "ldd -d -r /usr/lib/libneon.so" report? It should report the gss_release_oid symbol to be missing. In any case this is first of all a bug in neon. I'll have explicitly disabled neon from linking against kerberos for now. In some way the libtool archive, nor the library are complete. # ldd -d -r /usr/lib/libneon.so undefined symbol: gss_release_oid (/usr/lib/libneon.so) linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb7f4a000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7f1a000) libdl.so.2 => /lib/libdl.so.2 (0xb7f16000) libgssapi.so.4 => /usr/lib/libgssapi.so.4 (0xb7eff000) libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0xb7eb6000) libasn1.so.6 => /usr/lib/libasn1.so.6 (0xb7e85000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e81000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7d80000) libroken.so.16 => /usr/lib/libroken.so.16 (0xb7d6f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d42000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7d2f000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7d1d000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7cf0000) libc.so.6 => /lib/tls/libc.so.6 (0xb7bdc000) /lib/ld-linux.so.2 (0x80000000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7b08000) # Can you still reproduce this bug? I compiled net-misc/neon-0.26.3 (MIT kerberos installed and the kerberos useflag enabled) and this my ldd output (I hope this helps): # ldd /usr/lib/libneon.so linux-gate.so.1 => (0xffffe000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7e9b000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7d25000) libdl.so.2 => /lib/libdl.so.2 (0xb7d21000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7ba9000) libz.so.1 => /lib/libz.so.1 (0xb7b8c000) libm.so.6 => /lib/libm.so.6 (0xb7b66000) libc.so.6 => /lib/libc.so.6 (0xb7a34000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7a09000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7980000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb797d000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7951000) libresolv.so.2 => /lib/libresolv.so.2 (0xb793f000) /lib/ld-linux.so.2 (0x80000000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7936000) # mv /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.0.9.8.bak # ldd /usr/lib/libneon.so linux-gate.so.1 => (0xffffe000) libssl.so.0.9.8 => not found libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7dba000) libdl.so.2 => /lib/libdl.so.2 (0xb7db6000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7c3e000) libz.so.1 => /lib/libz.so.1 (0xb7c21000) libm.so.6 => /lib/libm.so.6 (0xb7bfb000) libc.so.6 => /lib/libc.so.6 (0xb7ac9000) /lib/ld-linux.so.2 (0x80000000) As you can see the gssapi and kerberos dependencies came from openssl, so neon does not depend on kerberos even if it is installed. (In reply to comment #10) > As you can see the gssapi and kerberos dependencies came from openssl, so neon > does not depend on kerberos even if it is installed. May be more complicated due to the differences between mit-krb5 and heimdal and due to the openssl/heimdal dependencies. Currently openssl has kerberos use flag triggering dependency on krb5 -- which actually means mit-krb5, since heimdal is unsupported upstream yet. The kerberos part of openssl is incompatible with heimdal to the extend I cannot simply handle -- I've tried a bit. But heimdal can depend on openssl, while mit-krb5 cannot. Also heimdal provides more features than mit-krb5, among them enough of libgssapi to build and run nfs-utils without net-libs/libgssglue, as Bryan Jacobs has proven at Bug #134064. See that and Bug #185899. So my guess is that openssl support for kerberos provides for mit-krb5 what heimdal provides for openssl. For openssl, I currently use USE="-kerberos" and hope my guess is right. For nfs-utils I follow the instructions of Bryan Jacobs. For subversion I use my heimdal-1.0.1 ebuild that adds to that of Bryan Jacobs the creation of pkg-config files. I think I had had problems with neon before creating those .pc files, but now neon just reads through pkg-config the right dependencies of libgssapi (that is those of heimdal at my system) and everything seems to work OK. (In reply to comment #11) > (In reply to comment #10) > > As you can see the gssapi and kerberos dependencies came from openssl, so neon > > does not depend on kerberos even if it is installed. > > May be more complicated due to the differences between mit-krb5 and heimdal > and due to the openssl/heimdal dependencies. But this should only matter when openssl is build, neon uses the crypto api functions of openssl and not the kerberos part in openssl. > Currently openssl has kerberos use flag triggering dependency on krb5 -- > which actually means mit-krb5, since heimdal is unsupported upstream yet. The > kerberos part of openssl is incompatible with heimdal to the extend I cannot > simply handle -- I've tried a bit. But heimdal can depend on openssl, while > mit-krb5 cannot. Also heimdal provides more features than mit-krb5, among them > enough of libgssapi to build and run nfs-utils without net-libs/libgssglue, as > Bryan Jacobs has proven at Bug #134064. See that and Bug #185899. So my guess > is that openssl support for kerberos provides for mit-krb5 what heimdal > provides for openssl. Correct, this is also my experience. But this is a openssl issue, neon uses openssl only for encryption and the gssapi for auth. They do not depend on each other. > For openssl, I currently use USE="-kerberos" and hope my guess is right. > For nfs-utils I follow the instructions of Bryan Jacobs. > For subversion I use my heimdal-1.0.1 ebuild that adds to that of Bryan > Jacobs the creation of pkg-config files. I think I had had problems with neon > before creating those .pc files, but now neon just reads through pkg-config the > right dependencies of libgssapi (that is those of heimdal at my system) and > everything seems to work OK. I've created a neon with kerberos ebuild (see Bug #197964 ). You could try if this also works your heimdal setup. But the issue here looks "resolved" to me since the current ebuilds have kerberos support disabled and re enabling it is a different problem. I forgot something: Since you emerged openssl without the kerberos use-flag could you check the dependencies of libneon (current stable ebuild 0.26.3) with "ldd /usr/lib/libneon.so" ? If this doesen't show any kerberos stuff we can be sure, that heimdal does not sneak so depndency into neon/openssl. Small note: You can use `scanelf`. It shows only direct dependencies. E. g.: scanelf -qF "%F: %n" /usr/lib/libneon.so /usr/lib/libssl.so (In reply to comment #13) You're right. No kerberos dependency in my libneon (or anything subversion related). And no problems with subversion or neon. To be sure, I've updated openssl (to 0.9.8g with USE="-kerberos") and recompiled heimdal, neon and subversion. Everything went well. My comment was probably irrelevant. Having been added to the CC list quite recently, apparently due to my interest in using heimdal with Gentoo, I should have paid more attention to the original report and its date. Moreover I can't find any traces of my previous problems with neon or subversion on my box, no overlay ebuilds, no patches, no leftover source trees from experiments or whatever. If I vaguely recall having such problems, either my memory is misleading or the problems were likely rather trivial, and definitely are long gone. Yes,the issue is gone as long as one compiles openssl with -kerberos while having heimdal installed. Or, one can take the ebuild from Bug #197964 and compile neon against heimdal directly. fixed neon-0.26.4 ebuild in cvs |