Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
cd subversion/clients/cmdline && /bin/sh /var/tmp/portage/subversion-1.3.0_rc4/work/subversion-1.3.0-rc4/libtool --tag=CC --silent --mode=link i686-pc-linux-gnu-gcc -L/var/tmp/portage/subversion-1.3.0_rc4/image//usr/lib -O3 -march=pentium4 -mmmx -msse -msse2 -msse3 -pipe -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pthread -D_LARGEFILE64_SOURCE -DNE_LFS -L/usr/lib -rpath /usr/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o lock-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client-1.la ../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib/libaprutil-0.la -lgdbm -ldb-4.2 -lexpat /usr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread -ldl /usr/lib/libneon.la -lz /usr/lib/libneon.so: undefined reference to `gss_release_oid' collect2: ld returned 1 exit status make: *** [subversion/clients/cmdline/svn] Error 1 !!! ERROR: dev-util/subversion-1.3.0_rc4 failed. !!! Function src_compile, Line 117, Exitcode 2 !!! make of subversion failed # emerge info Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.13.2 i686) ================================================================= System uname: 2.6.13.2 i686 Intel(R) Xeon(TM) CPU 3.00GHz Gentoo Base System version 1.12.0_pre11 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -mmmx -msse -msse2 -msse3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/spool/PBS" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.muni.cz/pub/linux/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 FFmpeg X Xaw3d aalib acpi alsa apache2 apm audiofile avi berkdb bidi bitmap-fonts bzip2 caca cdr crypt cscope curl dba divx divx4 divx4linux divx5 divx5linux dvd dvdr dvdread eds emacs emacs-w3 emboss encode exif expat f77 faad faad2 fam fame ffmpeg flash foomaticdb fortran fvwm fvwm2 gb gd gdbm ggi gif glut gpm gstreamer gtk gtk2 gtkhtml i8x0 icc imagemagick imlib imlib2 innodb ipv6 ithreads java javascript jpeg lcms leim libg++ libwww live lzo mad mcal mesa mikmod mmx mmx2 mng motif mozilla mp3 mpeg mule mysql ncurses network nls nptl ogg opengl oss pam pcre pda pdflib perl plotutils plugin png ppds pthread pthreads python qt qtx quicktime readline rtc samba sdl slp spell sse sse2 sse3 ssl tcltk tcpd tetex theora thread threads tiff truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vorbis win32 winvidix wmf xml xml2 xmms xosd xv xvid xvmc zeo zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY # I have re-emerged neon to be sure it is up-to-date and linked against current heimdal: * app-crypt/heimdal Latest version available: 0.7.1-r1 Latest version installed: 0.7.1-r1 Size of downloaded files: 4,414 kB Homepage: http://www.pdc.kth.se/heimdal/ Description: Kerberos 5 implementation from KTH License: as-is
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
