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.
Andrew Bartlett wrote:
On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote:
Christopher Aillon wrote:
3 /usr/lib64/firefox-2.0.0.2
Some of them are intentional, such as the above. It's either rpath or
munging LD_LIBRARY_PATH at startup if you want a working firefox.
RPATH is perfectly fine for these purposes.
Do we have a preference against wrapper scripts for munging
LD_LIBRARY_PATH (I think we should)?
The reason I ask is that I've been looking at the Fedora DS situation
(now a package in extras), where every binary is wrapped in a shell
script to munge the LD_LIBRARY_PATH, which just seems wrong to me.
Likewise, where should a package place 'internal only' libraries, such
as libslapd for Fedora DS, and some similar libraries in an eventual
Samba4 package (to avoid bloat by static linking shared internal
functionality)?
Andrew Bartlett
------------------------------------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
