Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 134064 - net-fs/nfs-utils-1.0.7-r2: add support for USE=heimdal
Summary: net-fs/nfs-utils-1.0.7-r2: add support for USE=heimdal
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Network Filesystems
URL:
Whiteboard:
Keywords:
: 186389 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-05-22 14:53 UTC by Martin Mokrejš
Modified: 2007-07-28 15:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
heimdal-0.8.1_rc3.ebuild (heimdal-0.8.1_rc3.ebuild,1.92 KB, text/plain)
2007-05-10 08:36 UTC, Honza Macháček
Details
heimdal-0.7.2-0.8.1_rc3.patch (heimdal-0.7.2-0.8.1_rc3.patch,1.95 KB, patch)
2007-05-10 08:41 UTC, Honza Macháček
Details | Diff
nfs-utils-1.0.12-r3.ebuild.patch (nfs-utils-1.0.12-r3.ebuild.patch,325 bytes, patch)
2007-05-10 08:45 UTC, Honza Macháček
Details | Diff
openldap-2.3.35-r1.ebuild.patch (openldap-2.3.35-r1.ebuild.patch,1.29 KB, patch)
2007-05-10 08:48 UTC, Honza Macháček
Details | Diff
php5-sapi.eclass.patch (php5-sapi.eclass.patch,620 bytes, patch)
2007-05-10 08:51 UTC, Honza Macháček
Details | Diff
php5_0-sapi.eclass.patch (php5_0-sapi.eclass.patch,665 bytes, patch)
2007-05-10 08:52 UTC, Honza Macháček
Details | Diff
php5_1-sapi.eclass.patch (php5_1-sapi.eclass.patch,665 bytes, patch)
2007-05-10 08:52 UTC, Honza Macháček
Details | Diff
php5_2-sapi.eclass.patch (php5_2-sapi.eclass.patch,661 bytes, patch)
2007-05-10 08:52 UTC, Honza Macháček
Details | Diff
evolution-data-server-1.8.3-r4.ebuild.patch (evolution-data-server-1.8.3-r4.ebuild.patch,1.26 KB, patch)
2007-05-10 08:56 UTC, Honza Macháček
Details | Diff
no_libgssapi.patch (no_libgssapi.patch,2.55 KB, patch)
2007-07-24 20:29 UTC, Bryan Jacobs
Details | Diff
nfs-utils-1.1.0-no_libgssapi.ebuild.diff (nfs-utils-1.1.0-no_libgssapi.ebuild.diff,277 bytes, patch)
2007-07-27 22:05 UTC, Honza Macháček
Details | Diff
config-details.patch (config-details.patch,1.07 KB, patch)
2007-07-27 22:08 UTC, Honza Macháček
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2006-05-22 14:53:47 UTC
nfs-utils currently requires me to have mit-krb5 package installed when kerberos use flag is set. This prevents me to have kerberos flag site-wide, as need nfs-utils and I do use heimdal and that clashes with mit-krb5.
Comment 1 Martin Mokrejš 2006-05-22 15:10:47 UTC
Depending on virtual/krb5 instead of mit-krb5 would help, but the sourcecode supports only mit-krb5 (README talks only about MIT krb5). So, I think the ebuild should be fixed not to request mit-krb5 at all. When mit-krb5 is installed, then it should enable the --enable-gss configure flag, otherwise you always have to use --disable-gss (or configure is fooled by headers and detects Heimdal, but breaks on compile).


Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-05-23 01:58:30 UTC
(In reply to comment #1)
> So, I think the
> ebuild should be fixed not to request mit-krb5 at all. When mit-krb5 is
> installed, then it should enable the --enable-gss configure flag, otherwise you
> always have to use --disable-gss (or configure is fooled by headers and detects
> Heimdal, but breaks on compile).

s/fixed/broken/ ? :) Automagic dependencies are a big evil... If nfs-utils doesn't support heimdal, then there's no point in switching the dependency to virtual/krb5. 

We can't remove the dependency, feel free to use /etc/portage/package.use to disable kerberos use flag for this ebuild. Reopen if you have a patch, CANTFIX meanwhile.
Comment 3 Martin Mokrejš 2006-05-23 02:53:43 UTC
I did fix that issue for myself temporarily by editing the ebuild and masking <net-fs/nfs-utils-1.0.7-r3, but most people do NOT have the experience with kerberos stuff so they wil raise the issues again. 

See my comment #2 in bug #103366 as well. The quick fix which would make the package compilable even when kerberos USE flag is set and only heimdal is installed should be the following:


# krb5-config --cflags
-I/usr/include/heimdal 
#

When kerberos use flag is set and when "heimdal" does NOT occur in the command output as shown above, --enable-gss should be passed to configure. In all other cases, --disable-gss should be forced to prevent configure to pick-up any headers resembling kerberos stuff. Imagine application silently linking over kerberos libs outside the control of portage. And, nfs-utils is one o the real examples.

For your fun see also:
bug #16824
bug #100868
bug #118508
bug #132189
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-05-23 02:59:19 UTC
(In reply to comment #3)
> The quick fix which would make the
> package compilable even when kerberos USE flag is set and only heimdal is
> installed should be the following:
> 
> 
> # krb5-config --cflags
> -I/usr/include/heimdal 

If that works, I don't see anything wrong w/ that. All I was saying is that dropping the dependency and leaving this up to some automagic detection isn't really an option...
Comment 5 Martin Mokrejš 2006-05-23 03:04:32 UTC
BTW, the check for "heidmal" in krb5-config output I proposed also because of the reason that when people keep /usr/heimdal/ installed as well and have that in the PATH, this magic detection would still force --disable-gss and thus make nfs-utils not to break on compile.
Comment 6 SpanKY gentoo-dev 2006-05-23 17:36:38 UTC
simply changing the DEPEND doesnt fix anything ... verify the code builds correctly with all virtual/krb5 providers and i'll change it ... otherwise, no dice

from an older ebuild:
DEPEND="${RDEPEND}
	>=sys-apps/portage-2.0.51
	!nonfsv4? (
		>=dev-libs/libevent-1.0b
		>=net-libs/nfsidmap-0.9
	)
	kerberos? ( app-crypt/mit-krb5 )"
	# kth-krb doesn't provide the right include
	# files, and nfs-utils doesn't build against heimdal either, 
	# so don't depend on virtual/krb.
	# (04 Feb 2005 agriffis)
Comment 7 Martin von Gagern 2007-02-25 23:22:00 UTC
Grepping for heimdal in the nfs-utils-1.0.10 sources shows that some effort must have gone into trying to support heimdal. Looking at the ChangeLog I find this:

2005-08-26 Kevin Coffman <kwc@citi.umich.edu>
        Changes to allow gssd/svcgssd to build when using Hiemdal Kerberos
        libraries.  Note that there are still run-time issues preventing
        this from working when shared libraries for libgssapi and librpcsecgss
        are used.

A bit difficult to find due to the misspelling. I don't know what issues those are, but this seems a long time ago, so they might be solved by now.

However, the thing won't even compile. I get
  context_heimdal.c:81: error: dereferencing pointer to incomplete type
which is because in /usr/include/heimdal/gssapi.h you find these two lines:
  struct gss_ctx_id_t_desc_struct;
  typedef struct gss_ctx_id_t_desc_struct *gss_ctx_id_t;
but the definition of gss_ctx_id_t_desc_struct is in no installed header.
nfs-utils is accessing ctx->auth_context, ctx->more_flags and ctx->lifetime.
Looking at the heimdal ChangeLog I found this record:

2003-05-21  Love Hörnquist Åstrand  <lha@it.su.se>
        - don't export gss_ctx_id_t_desc_struct and gss_cred_id_t_desc_struct

To me this seems like the NFS people were using in 2005 a feature that had already been deprecated in 2003, using some obscure internal definitions.

http://nfs.cvs.sourceforge.net/nfs/nfs-utils/utils/gssd/context_heimdal.c lists only two revisions of this file, one in 2004 and one in 2005. I don't know if this CVS is in active use, though, as it lacks tags for the latest releases.

Heimdal support seems to be a frequent issue on the nfs mailing lists. I have't looked through http://www.google.com/search?q=site%3Alinux-nfs.org+heimdal yet.

Summary: not supporting heimdal with nfs-utils-1.0.10 still seems the right choice, and now I have a better idea why that's the case.
Comment 8 Martin Mokrejš 2007-02-27 18:30:35 UTC
But then force -kerberos if no mit-krb is installed. I am not asking you to fix Heimdal support, I am proposing to mask heimdal support until it is functional.
Comment 9 Martin von Gagern 2007-02-27 18:37:31 UTC
(In reply to comment #8)

The use flag is for kerberos, not for heimdal. So when you set USE=kerberos, portage assumes that you want kerberos support in any package providing it unless you tell it otherwise. And nfs-utils does provide kerberos, and tells you that to provide this functionality it needs to have mit kerberos, not heimdal.
Now you as a system administrator have two options:
1. decide you need kerberos, and replace heimdal with mit kerberos or
2. decide you don't need kerberos in nfs-utils, and
   echo "net-fs/nfs-utils -kerberos" > /etc/portage/package.use

Neither of these options is clearly the "correct" one, so portage complaining and leaving the choice to the administrator is the correct thing to do.

Of course we could introduce a mitkrb use flag or something like this, to enable kerberos when it depends on mit, but I see no point in this, because there are not many ebuilds affected, and for a single ebuild the above configuration (ehich was already pointed out in comment #2, btw) is less work.
Comment 10 Martin Mokrejš 2007-02-27 18:43:30 UTC
Yes, I do have -kerberos in my package.use line for nfs-utils. But I do believe
when a package is not not to compile with heimdal (which provides the kerberos virtual), it should be fixed in the ebuild.

Yes, several times I have proposed to have more fine-grained USE flags than just "kerberos". Kerberos herd people know that and the bugreport is still opened I think. ;) Anyway, do whatever yoy want, I can live with package.use file contents.
Comment 11 Martin Mokrejš 2007-02-27 18:46:52 UTC
> Of course we could introduce a mitkrb use flag or something like this, to
> enable kerberos when it depends on mit, but I see no point in this, because
> there are not many ebuilds affected, and for a single ebuild the above
> configuration (ehich was already pointed out in comment #2, btw) is less work.

And, a number of packages supports only MIT-KRB while not heimdal.
Comment 12 SpanKY gentoo-dev 2007-02-27 18:47:59 UTC
comment #6 still stands ...

while comment #7 looks promising, i dont use kerberos myself so i have no way of verifying it
Comment 13 Martin von Gagern 2007-02-27 18:58:08 UTC
(In reply to comment #9)
>    echo "net-fs/nfs-utils -kerberos" > /etc/portage/package.use

Before others read this while tired and thus break their whole system:
of course you should append to the file, not overwrite it:

echo "net-fs/nfs-utils -kerberos" >> /etc/portage/package.use

(In reply to comment #10)
> Yes, several times I have proposed to have more fine-grained USE flags than
> just "kerberos".
(And also in reply to comment #11)
> And, a number of packages supports only MIT-KRB while not heimdal.

This sounds like an enhancement request to have a USE flag called "mitkrb". Doesn't well fit the summary of this report here. Disabling gssapi altogether for a USE=heimdal would be counterintuitive, as this wont "use heimdal".
Maybe you should open a new request for this.

Still, I don't think that's a good idea. When I decide to use kerberos, I look at the list of use flags, find kerberos, enable it, and then stop. I would not notice mitkrb, even if I were using MIT-KRB. And automatic useflags for installed packages were removed quite a while ago, for good reasons I think.
Comment 14 Martin Mokrejš 2007-02-27 19:24:09 UTC
See bug #16824, #103366, #114759 (maybe offtopic here), #135238, #113052, ... and look into some closed bugs related to kerberos and see that mostlym the issue is that "kerberos" kicks in while often only mit-krb is supported (and not heimdal).
Comment 15 Martin von Gagern 2007-02-28 08:17:05 UTC
Getting heimdal support probably depends on bug #168509 being resolved in such a way that alows us to have heimdal and libgssapi installed at the same time.

I wrote an email to heimdal and nfs mailing lists, trying to clarify situation. You may follow the corresponding mail threads here:
http://linux-nfs.org/pipermail/nfsv4/2007-February/005768.html
http://www.mail-archive.com/heimdal-discuss@sics.se/msg00391.html

So far (while I've been waiting for the heimdal archive to give me the link to my mail) there has been one reply from an NFS dev. Looks like we should wait for Heimdal 0.8 to be released.
Comment 16 Honza Macháček 2007-05-10 08:36:29 UTC
Created attachment 118725 [details]
heimdal-0.8.1_rc3.ebuild
Comment 17 Honza Macháček 2007-05-10 08:37:38 UTC
(In reply to comment #15)
> I wrote an email to heimdal and nfs mailing lists...

Thank you for that thread. It allowed me to adapt Harald Barth's ebuild and get finally what looks like a working installation of heimdal 0.8.1_rc3.

The ebuild plus several modifications of kerberos dependent packages needed follow.
Comment 18 Honza Macháček 2007-05-10 08:41:41 UTC
Created attachment 118727 [details, diff]
heimdal-0.7.2-0.8.1_rc3.patch

My 0.8.1_rc3 ebuild as a patch against Harald Barth's 0.7.2. Installs into /usr/heimdal prefix, does not create its own separate slot. krb5-config is symlinked in /usr/bin and /usr/heimdal/lib scanned by ldconfig after the installation -- may be not all of this is necessary, but it has seemed to solve difficulties with kerberos using packages during my strugle with the modified system.
Comment 19 Honza Macháček 2007-05-10 08:45:32 UTC
Created attachment 118728 [details, diff]
nfs-utils-1.0.12-r3.ebuild.patch

Looks like for nfs-utils just changing the kerberos dependence from app-crypt/mit-krb5 to virtual/krb5 suffices.
Comment 20 Honza Macháček 2007-05-10 08:48:37 UTC
Created attachment 118729 [details, diff]
openldap-2.3.35-r1.ebuild.patch

net-nds/openldap is slightly trickier, must be adapted to use krb5-config instead of hardcoded include and library directories.
Comment 21 Honza Macháček 2007-05-10 08:51:48 UTC
Created attachment 118731 [details, diff]
php5-sapi.eclass.patch

dev-lang/php is very tricky, the kerberos path being hardcoded into several eclasses.
Comment 22 Honza Macháček 2007-05-10 08:52:12 UTC
Created attachment 118733 [details, diff]
php5_0-sapi.eclass.patch
Comment 23 Honza Macháček 2007-05-10 08:52:31 UTC
Created attachment 118734 [details, diff]
php5_1-sapi.eclass.patch
Comment 24 Honza Macháček 2007-05-10 08:52:54 UTC
Created attachment 118735 [details, diff]
php5_2-sapi.eclass.patch
Comment 25 Honza Macháček 2007-05-10 08:56:47 UTC
Created attachment 118736 [details, diff]
evolution-data-server-1.8.3-r4.ebuild.patch

gnome-extra/evolution-data-server needs to get includes and libs directories from krb5-config separately; getting the general prefix does not suffice, and with the includes and libs configuration might be redundant, but I haven't tried to remove that one setting. This version works for me, so I'm happy with it, send it forward, and rest.
Comment 26 SpanKY gentoo-dev 2007-05-10 22:45:05 UTC
this bug is just about nfs-utils ... if you have changes for any other package, file a new bug report (1 per package)
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2007-07-24 06:13:56 UTC
*** Bug 186389 has been marked as a duplicate of this bug. ***
Comment 28 Martin Mokrejš 2007-07-24 09:29:35 UTC
Will someone commit these patches, please, without asking the user to open several bugreports? Is it really that necessary? Thanks.
Comment 29 Honza Macháček 2007-07-24 10:22:56 UTC
(In reply to comment #28)
> Will someone commit these patches, please, without asking the user to open
> several bugreports? Is it really that necessary? Thanks.
> 

Well, opening separate bugs may be the easiest way to do it after all. Different packages have different maintainers, and properly sorted bugs in bugzilla may be the best way to reach them.

I'm going to do that as soon as I try upgrading my heimdal to 1.0. The heimdal developement is really fast these days -- while in portage we still have 0.7.2 only. So heimdal upgrade first, a bug for it next, and all the related bugs afterwards.

Let's leave to this bug just changing the dependence of net-fs/nfs-utils from app-crypt/mit-krb5 to virtual/krb5.
Comment 30 Honza Macháček 2007-07-24 11:17:18 UTC
(In reply to comment #29)

Bug #185899 for heimdal upgrade already exists. Should it be added here as one this depends on?

My ebuild derived from that of Harald Barth has installed successfully on my laptop meanwhile; it does not depend on so many patches as the ebuild by Bryan Jacobs, that one apparently continuing the line of the official tree heimdal ebuilds. Let's move the discussion to the Bug #185899.
Comment 31 Bryan Jacobs 2007-07-24 16:23:23 UTC
(In reply to comment #30)
> (In reply to comment #29)
> 
> Bug #185899 for heimdal upgrade already exists. Should it be added here as one
> this depends on?
> 
> My ebuild derived from that of Harald Barth has installed successfully on my
> laptop meanwhile; it does not depend on so many patches as the ebuild by Bryan
> Jacobs, that one apparently continuing the line of the official tree heimdal
> ebuilds. Let's move the discussion to the Bug #185899.
> 

Most of the Gentoo patches are not strictly necessary, however I did review them and each had a reason :-).  For example, one of them is required to link correctly against Gentoo's libdb independently of whether libdb3 or libdb4 is installed.  One of them externalizes the readline so we don't have a special Heimdal copy.

They may not be necessary for your situation, but the patches I left in (about half of the ones that 0.7.2 had) were all things that looked to be positive and   the versions I posted apply cleanly.  "fewer patches" is not "better".

And, while I did get Heimdal to handle prefixing gracefully, there ARE a number of other ebuilds in the tree that'd have to be fixed.  I've opened a few bugs about it.
Comment 32 Honza Macháček 2007-07-24 17:36:02 UTC
(In reply to comment #31)
Thanks for your explanation (by the way, why here and not at the heimdal update bug). I'm going to try adapting your ebuild for 1.0.1_rc1 (not to install one version twice when there is at least new release candidate available) and upgrading my system as soon as it accommodates to the 1.0 (Harald Barth's style) just installed. I think I'll want to stick to the separate installation directory, since it may solve Bug #168509 -- I'm changing on the fly the ebuilds that complain about that to use krb5-config, and I'm going to file appropriate bugs for them.

Should I direct my (sporadic and limited) efforts some specific way to better help with heimdal on Gentoo? Should I try some tests or experiments? (I'm currently reinstalling system on my 32-bit Sempron 2600+/Via K8N800 laptop after the original harddisk has died. I haven't installed app-crypt/libgssapi yet, nothing I've installed so far apparently required it, so should I, for example, try, what might installing it do to my system, or rather explore, how far I can get without it?)
Comment 33 Bryan Jacobs 2007-07-24 17:44:42 UTC
(In reply to comment #32)
> (In reply to comment #31)
> Thanks for your explanation (by the way, why here and not at the heimdal update
> bug). I'm going to try adapting your ebuild for 1.0.1_rc1 (not to install one
> version twice when there is at least new release candidate available) and
> upgrading my system as soon as it accommodates to the 1.0 (Harald Barth's
> style) just installed. I think I'll want to stick to the separate installation
> directory, since it may solve Bug #168509 -- I'm changing on the fly the
> ebuilds that complain about that to use krb5-config, and I'm going to file
> appropriate bugs for them.
> 
> Should I direct my (sporadic and limited) efforts some specific way to better
> help with heimdal on Gentoo? Should I try some tests or experiments? (I'm
> currently reinstalling system on my 32-bit Sempron 2600+/Via K8N800 laptop
> after the original harddisk has died. I haven't installed app-crypt/libgssapi
> yet, nothing I've installed so far apparently required it, so should I, for
> example, try, what might installing it do to my system, or rather explore, how
> far I can get without it?)
> 

Sorry, didn't see you on the CCs for the other bug.

Look at http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html - I was unable to build nfs-utils against Heimdal without the use of libgssapi.  I think it's just a problem with their configure scripts, but I don't know for sure.  In an ideal world, we'd only need to install libgssapi with mit-krb5 - deps for nfs-utils would be:
|| (  
( >=app-crypt/heimdal-1.0 )
( >=app-crypt/libgssapi-0.11 app-crypt/mit-krb5 )
)

Producing a patch to make nfs-utils build with gss support (we don't care about spkm3, do we?) without libgssapi would be useful.  In fact, it would make the whole library-collision issue go away as we could just make heimdal and libgssapi conflict.

Comment 34 SpanKY gentoo-dev 2007-07-24 18:18:55 UTC
yes, we're going to make you file several bugs ... this one is just about nfs-utils

and once again, the state of this bug is reflected in comment #6
Comment 35 Bryan Jacobs 2007-07-24 20:29:08 UTC
Created attachment 125912 [details, diff]
no_libgssapi.patch

With this patch, nfs-utils builds against Heimdal 1.0 (and NOT against libgssapi).

So, there are two installation options:
mit-krb5 -> libgssapi <-> librpcsecgss -> nfs-utils <- libgssapi
heimdal <-> nfs-utils <- librpcsecgss <- heimdal
Arrows indicate dynamic linking.  As in, "libgssapi is linked against Heimdal"
Comment 36 Honza Macháček 2007-07-27 22:05:50 UTC
Created attachment 126187 [details, diff]
nfs-utils-1.1.0-no_libgssapi.ebuild.diff

Ebuild modification to use Bryan Jacobs' patch. Slight patch of the configure script added to work well with the pkg-config aware app-crypt/heimdal ebuild (Bug #185899) and net-libs/librpcsecgss using that (Bug #186392).
Comment 37 Honza Macháček 2007-07-27 22:08:56 UTC
Created attachment 126190 [details, diff]
config-details.patch

Patch for the configure script to read correctly the kerberos version for heimdal as well as for mit-krb5 and to consistently used the librpcsecgss libraries settings got from pkg-config through testing for prerequisites.
Comment 38 Bryan Jacobs 2007-07-27 22:16:03 UTC
(In reply to comment #37)
> Created an attachment (id=126190) [edit]
> config-details.patch
> 
> Patch for the configure script to read correctly the kerberos version for
> heimdal as well as for mit-krb5 and to consistently used the librpcsecgss
> libraries settings got from pkg-config through testing for prerequisites.
> 

You do realize that this only solves one of two problems, right?  Even if the link-time works, the packages won't work at run time because of the dynamic linker's inability to distinguish two different libgssapi.so.2 files in the LDPATH.  librpcsecgss links libgssapi, nfs-utils links Heimdal, and nfs-utils links librpcsecgss.  This means that nfs-utils needs to load BOTH libgssapis to run - which, as far as I know, cannot be done if they can't be distinguished.  I  could be wrong (I don't know everything about linking), but I'm pretty sure the only way to resolve this is either to statically link something or to eliminate the name clash.  The solution I implemented in Bug #168509 is a good temporary fix, in my opinion.
Comment 39 Honza Macháček 2007-07-28 04:29:29 UTC
(In reply to comment #38)

Sorry for unclear commentary.

That patch is only a part of my above mentioned ebuild that uses your patch to avoid app-crypt/libgssapi.

Thanks to your work, putting of heimdal into separate directory may be in fact unnecessary and dealing with dumb ebuilds or configuration scripts that make assumptions on the installation directories may not be needed. I think that converting them to use more general configuration methods is a good thing anyway; nfs-utils actually do use those mechanisms, pkg-config for net-libs/librpcsecgss and krb5-config for kerberos, there are just two inconsistencies in its configure script.

So I recommend my config patch (or its better analogy if I've got something wrong), but it's just a small part, your patch for heimdal use is much more important.
Comment 40 Martin von Gagern 2007-07-28 10:33:52 UTC
(In reply to comment #38)
> Even if the
> link-time works, the packages won't work at run time because of the dynamic
> linker's inability to distinguish two different libgssapi.so.2 files in the
> LDPATH.  librpcsecgss links libgssapi, nfs-utils links Heimdal, and nfs-utils
> links librpcsecgss.  This means that nfs-utils needs to load BOTH libgssapis
> to run - which, as far as I know, cannot be done if they can't be
> distinguished.

Ensuring different names for the different libraries ensures they both can be loaded at the same time. But how about the symbols in them? We do have many symbols common to both implementations, and usually the symbols would be linked against the first loaded library that does provide them. Only the -Bdirect linker switch proposed in bug 114008 would specify the library file from which the symbol should be used. Are we sure that we can rely on a fixed order in which the libraries will be loaded? Can the library which is loaded later cope with the fact that some symbols it provides will always be used from the library loaded first instead? I feel there might be trouble ahead yet.

Is there a chance we get both nfs-utils and librpcsecgss linked against the same libgssapi?
Comment 41 Bryan Jacobs 2007-07-28 15:59:34 UTC
(In reply to comment #40)
> Is there a chance we get both nfs-utils and librpcsecgss linked against the
> same libgssapi?
> 

Yes, I've already linked both against Heimdal.