[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-directory-devel] Re: RPATH status



On Mon, 2007-03-12 at 06:30 -0600, Richard Megginson wrote:
> David Boreham wrote:
> >
> > Some more info on this:
> >
> > FDS was designed to install at an arbitrary subdirectory in the 
> > filesystem.
> > rpath only supports absolute paths and paths relative to the current 
> > working
> > directory, not the location of the binary (some platforms have some 
> > support
> > for rpath relative to the main binary location but at the time this 
> > was last
> > looked at seriously, that support was spotty and incomplete).
> > And so we have wrappers. They allow a user to add one directory
> > to their path and run any FDS command without regard to setting
> > LD_LIBRARY_PATH.
> >
> > To remove the wrappers you'd need to give up something :
> > install at a fixed location (and use absolute rpaths); don't give
> > users the convenience of running commands without setting
> > LD_LIBRARY_PATH themselves; only run on platforms
> > that have support for relative-to-binary rpath.
> We're using the first option on Fedora.  We install all of the libraries 
> in system locations, so there is no need to set rpath or have wrapper 
> scripts for the command line programs.  The only one in question is 
> libslapd.so, and we could put that in the system $_libdir, or some other 
> directory that is "approved" by the FHS.  

Yeah, that seems very out of place in $_libdir

> We were planning to get rid of 
> the wrapper scripts sooner or later on Fedora.  Does this have to be 
> sooner?  Are the wrapper scripts causing some problem (other than an 
> aesthetic one)?

Not in particular, but an interesting point was made on the fedora-devel
list:  If the 'wrapped' binary forks a child, then that unrelated child
also inherits the environment, which may not be desired. 

> We require the use of wrapper scripts on almost every other platform, 
> including RHEL4 - and, AFAIK, on other linux distros that put the NSPR 
> and NSS bundled with the Mozilla clients in the system _libdir.  Fedora 
> solved this problem by making NSPR and NSS independent of Mozilla.

In Samba4, we 'solved' the similar problems (on a smaller scale) by
including the code statically.  I can't claim that's a Superior
solution...

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]