Both app-crypt/heimdal-0.7.2-r3 and app-crypt/libgssapi-0.10 install a file /usr/lib/libgssapi.so. I guess installing them both at the same time should be prevented through appropriate dependency settings. Just now this had the effect of preventing me from building net-misc/openssh with the kerberos USE flag: [...]gcc -o sshd sshd.o [...] -lgssapi [...] gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds': gss-serv-krb5.c:(.text+0x286): undefined reference to `gss_krb5_copy_ccache' grep told me that libgssapi.so.4 from heimdal included this symbol, but libgssapi.so was symlinked to libgssapi.so.2 from libgssapi-0.10, which I had installed while examining bug 134064.
*** This bug has been marked as a duplicate of bug 124494 ***
(In reply to comment #1) > *** This bug has been marked as a duplicate of bug 124494 *** I believe this dup is wrong for several reasons: bug 124494 has "implicit declaration", a compiler problem fixed by changes to the preprocessor mechanics. I have "undefined reference", a linker problem, caused by linking against the wrong version of a library. Two ebuilds both installing the same symlink pointing at different files without special care in post-install and post-remove phases will almost certainly cause trouble. The link target depends on emerge order. Unmerging one package will remove the symlink, requiring the other ebuild to be reemerged or the symlink added manually. Those symlink issues very likely will affect other ebuilds as well, so this is not specific to openssh. The fact that bug 124494 has been resolved fixed for almost a year now, and the fix has been included in the upstream sources and is present in my sources, may serve as further proof that this is not the same bug.
If Heimdal provides a libgssapi, can programs that normally depend on app-crypt/libgssapi be compiled with only Heimdal, or would drastic changes be needed/Heimdal simply doesn't support everything libgssapi does?
(In reply to comment #3) > If Heimdal provides a libgssapi, can programs that normally depend on > app-crypt/libgssapi be compiled with only Heimdal, or would drastic changes be > needed/Heimdal simply doesn't support everything libgssapi does? I have no experience there myself, yet. According to http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html the important thing is probably whether the heimdal libgssapi supports other mechanisms as well. I don't know if it does. http://www.mail-archive.com/heimdal-discuss@sics.se/msg00395.html reports a working setup with heimdal installed to a different prefix and the CITI libgssapi in /usr/lib as wrapper for heimdal and others. I haven't found the time to write a heimdal 0.8 rc ebuild, but I guess that getting bug 134064 resolved, i.e. getting nfs-utils to work with heimdal, should be a strong indication that a setup works with these two libs. Though the question remains if any program currently linking against the heimdal libgssapi would be happy to use the CITI libgssapi instead, or if we had to provide the path to the heimdal version when linking.
*** Bug 171563 has been marked as a duplicate of this bug. ***
If people with such a conflicting setup build nss_ldap with kerberos support (after bug 165638 gets fixed), they will end up with a libnss_ldap.so.2 that requires a symbol not provided by libgssapi. This is due to an upstream bug http://bugzilla.padl.com/show_bug.cgi?id=328 and can cause severe runtime issues while going unnoticed at compiletime. libnss_ldap will fail with this message: symbol lookup error: /lib/libnss_ldap.so.2: undefined symbol: gss_krb5_ccache_name
Created attachment 125790 [details] libgssapi-0.11.ebuild libgssapi installed into /usr/libgssapi_citi/lib, with appropriate LD_PATH and PKG_CONFIG additions.
Created attachment 125791 [details] libgssapi.envd env.d file to enable compiling against CITI's libgssapi mechglue
Created attachment 125793 [details, diff] change_lib_version.patch Patch to change the version number of libgssapi.so to .20 from .2, so that Heimdal's and CITI's libraries no longer collide in dynamic linking search.
(In reply to comment #8) > libgssapi.envd Instead (or in addition to?) setting LDPATH and thus relying on environment variables, can we get -rpath passed to the linker? Like this (untested): Libs: -Wl,-rpath -Wl,/usr/libgssapi_citi/lib/ -lgssapi -ldl In that case we wouldn't need LDPATH at all, and we wouldn't need to modify the runtime environment either. Only at compile time the package config would need to be accessible. I'd prefer not to rely on environment for probably system critical functionality.
*** Bug 190280 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Created an attachment (id=125793) [edit] > change_lib_version.patch > > Patch to change the version number of libgssapi.so to .20 from .2, so that > Heimdal's and CITI's libraries no longer collide in dynamic linking search. > this problem will be solved in the next release of libgssapi the package will be renamed to libgssglue http://marc.info/?l=linux-nfsv4&m=118880710222040&w=2
(In reply to comment #12) > this problem will be solved in the next release of libgssapi > the package will be renamed to libgssglue A rename is good news. Although it is not the package name that counts, but rather the library name. In fact you might even leave the package name alone for the time being, and then rename the whole package with some future batch of portage updates to package names. This would provide a clean migration path and avoid the rather ugly hack of creating an empty libgssapi-999 which only depends on libgssglue.
(In reply to comment #13) > (In reply to comment #12) > > this problem will be solved in the next release of libgssapi > > the package will be renamed to libgssglue > > A rename is good news. Although it is not the package name that counts, but > rather the library name. In fact you might even leave the package name alone > for the time being, and then rename the whole package with some future batch of > portage updates to package names. This would provide a clean migration path and > avoid the rather ugly hack of creating an empty libgssapi-999 which only > depends on libgssglue. > the package and the lib will be renamed the citi libgss is only an gss switcher.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > this problem will be solved in the next release of libgssapi > > > the package will be renamed to libgssglue > > > > A rename is good news. Although it is not the package name that counts, but > > rather the library name. In fact you might even leave the package name alone > > for the time being, and then rename the whole package with some future batch of > > portage updates to package names. This would provide a clean migration path and > > avoid the rather ugly hack of creating an empty libgssapi-999 which only > > depends on libgssglue. > > > the package and the lib will be renamed > the citi libgss is only an gss switcher. > the new libgssglue has bin released http://www.citi.umich.edu/projects/nfsv4/linux/
Closing as net-libs/libgssglue solves the issue.
