If you have both heimdal and mit-krb5 installed, then whe the ebuild for freeradius tries to link, it gets confused by duplicate library names that have the same symbols, and you get MDS errors on linkage. Here is what my system layout looked like for the libraries in question: Package owns Filename app-crypt/heimdal-0.6 /usr/lib/libkrb5.a app-crypt/heimdal-0.6 /usr/lib/libkrb5.la app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so.3 app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so.3 app-crypt/mit-krb5-1.3.1 /usr/lib/libkrb5.so.3.2 Package owns Filename app-crypt/heimdal-0.6 /usr/lib/libcom_err.a sys-fs/e2fsprogs-1.34 /usr/lib/libcom_err.a app-crypt/heimdal-0.6 /usr/lib/libcom_err.la app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so sys-fs/e2fsprogs-1.34 /usr/lib/libcom_err.so app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so.3 app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so.3 app-crypt/mit-krb5-1.3.1 /usr/lib/libcom_err.so.3.0 I'm not particularly happy that libcom_err has different package ownerships (it looks like we have some name clashing going on in /usr/lib...at least the version numbers are clashing...) I would think it would be preferable to have some sort of blocking going on between mit-krb5 and heimdal, since they try to supply roughly the same thing. I did not explicitly install either of them. "emerge -p depclean" tells me that heimdal was ok to remove, so I did (after running quickpkg on it ;). This seems to clear up the freeradius build. I am not sure if this should be considered a bug with the krb libraries, freeradius or blocking mechanisms. Reproducible: Didn't try Steps to Reproduce: 1. Portage 2.0.50-r3 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22-gentoo-r7) ================================================================= System uname: 2.4.22-gentoo-r7 i686 Celeron (Coppermine) Gentoo Base System version 1.4.3.13 distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="http://gentoo.ccccom.com http://128.213.5.34/gentoo/ http://gentoo.binarycompass.org http://cudlug.cudenver.edu/gentoo/ http://mirror.cpsc.ucalgary.ca/mirror/gentoo.org" MAKEOPTS="-j12" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acl alsa apache2 apm arts avi berkdb bindist bonobo canna cdr cjk crypt cscope cups curl dga directfb doc dvb dvd encode esd fastcgi fbcon foomaticdb freewnn gb gd gdbm ggi gif gnome gpm gstreamer gtk gtk2 imap imlib innodb ipv6 jack java jpeg junit kde kerberos lcms ldap libg++ libgda libwww mad mcal mikmod mmx motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl plotutils png postgres python qt quicktime readline ruby samba sasl scanner sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usb wmf wxwindows x86 xml xml2 xmms xv zeo zlib"
Created attachment 28856 [details] list of ebuild depend on app-crypt/mit-krb5 for some reason Gentoo developers choose heimdal as default for virtual/krb5 while there are a lot ebuilds depend on app-crypt/mit-krb5 if we use 'kerberos'.
Tuan Van: Do all those applications really need krb5? I have taken a look at them and I think a few provide their authentication servicies through SASL. In that case (and from my limited understanding) SASL is the package that really should depend on virtual/krb5... maybe I'm missing anything
fixed in freeradius, the others have to be fixed by the heimdal/mit-krb5 maintainer
I think both krb related virtual should be dropped. Please see bug #16824 for a suggestion. It is reasonable to request all three kerberos implementation installed on the same host. 1. They can coexist because they reside in _different_location. 2. Do not use econf in ebuilds but call directly ./configure so that econf doesn't set the default gentoo prefix, manpath, infopath etc. 3. Once you install into _standard_ and _well_tested_ locations you won't have headers/libs clashinge either and magically other package configure will find the kerberos trees easily (you awoid the magic looking what synmbols in in krb5 libs in /usr/lib).
Recent heimdal configure scripts can detect system-wide com_err and use that instead of using its own. See, I have installed heimdal into /usr/heimdal prefix, as is the default and it happily uses com_err from /usr/lib. Do not relocate heimdal, kth-krb into /usr and you will be done with such problems. # ldd /usr/heimdal/bin/telnet linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7fcf000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7fcc000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7ed0000) libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7e78000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e4b000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7d71000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7d5c000) libc.so.6 => /lib/tls/libc.so.6 (0xb7c2c000) /lib/ld-linux.so.2 (0xb7fe9000) # /usr/heimdal/bin/telnet --version Encryption is verbose telnet (Heimdal 0.7pre3) Copyright 1999-2005 Kungliga Tekniska H
Recent heimdal configure scripts can detect system-wide com_err and use that instead of using its own. See, I have installed heimdal into /usr/heimdal prefix, as is the default and it happily uses com_err from /usr/lib. Do not relocate heimdal, kth-krb into /usr and you will be done with such problems. # ldd /usr/heimdal/bin/telnet linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7fcf000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7fcc000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7ed0000) libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7e78000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e4b000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7d71000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7d5c000) libc.so.6 => /lib/tls/libc.so.6 (0xb7c2c000) /lib/ld-linux.so.2 (0xb7fe9000) # /usr/heimdal/bin/telnet --version Encryption is verbose telnet (Heimdal 0.7pre3) Copyright 1999-2005 Kungliga Tekniska Högskolan Send bug-reports to heimdal-bugs@pdc.kth.se # ls /usr/heimdal/lib libasn1.a libeditline.la libhdb.a libkadm5clnt.la libkafs.a libkrb5.la libroken.a libsl.la libasn1.la libgssapi.a libhdb.la libkadm5srv.a libkafs.la libotp.a libroken.la libss.a libeditline.a libgssapi.la libkadm5clnt.a libkadm5srv.la libkrb5.a libotp.la libsl.a libss.la #
*** Bug 145019 has been marked as a duplicate of this bug. ***
*** Bug 178357 has been marked as a duplicate of this bug. ***
This bug is really no longer applicable ;) Therefor I'll close it - you can state the development especially of the heimdal development in gentoo in bug #185899.
