On Wed, 2014-02-26 at 18:01 +1100, NeilBrown wrote: > On Tue, 25 Feb 2014 22:06:58 -0800 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > > > > On Feb 25, 2014, at 9:16 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > > > > See $SUBJ > > > > > > Shared libraries are usually versioned so you can release a new version with > > > an incompatible API and gradually transition to it. > > > > > > A rpc.mountd dlopens libnfsjunct.so with no version it is effectively > > > prohibited from ever changing the API in an incompatible way. > > > > There is an API version field that mountd can examine before using the plug-in. .so symlinks to whichever library version is the blessed one. > > What exactly does "blessed one" mean... > > Maybe the question I want to ask is: > Is libnfsjunct.so something that only rpc.mountd would ever use and it could > not possibly make any sense for anything else to ever use it? > > If so, then we probably don't want to install the .so.0 or .so.0.0.0 files > and maybe should give libnfsjunct.so a different suffix because it is not > "shared" in any sense (I wanted to suggest ".lo" for loadable object, but I > think that is already used). > > If not, then you could conceivably have two tool installed which use > different version, so it doesn't make sense for either to be "blessed". > The bare ".so" name would be "the version that should be used when building > anything from source". > > Does the question have a simple answer? Shared objects are always called .so, however private modules SHOULD be installed in a package private directory and no in /usr/lib[64] Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
