[sldev] Re: shared objects output during standalone build

[Paul TBBle Hampson]

On Sun, Jul 15, 2007 at 02:00:31AM -0500, Callum Lerwick wrote:
> On Sun, 2007-07-15 at 04:00 +1000, Paul TBBle Hampson wrote:
>> The only issue then is convincing SCons to put an rpath into the client.

> Bad idea:

In short, rpath has its uses. The issue arises because 90% of rpath
usage used to come from libtool's "make install" handler rpathing
everthing to the prefix, which is not what most packagers want.

Everything below this point is explanation of the above.

Something to keep in mind while looking at the below, is that the shared
objects being created at the moment by the SConstruct script don't have
SONAME or NEEDED headers (except llimage got a NEEDED header for
llimagej2coj) so ld.so _can't_ do any better than load the first one it
finds in its search path. (Which rpaths appear at the front of)

> http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544

"Often, rpath is used because a binary is looking for libraries in a
non-standard location (standard locations are /lib, /usr/lib, /lib64,
/usr/lib64). If you are storing a library in a non-standard location
(e.g. /usr/lib/foo/), you should include a custom config file in
/etc/ld.so.conf.d/."

This is daft, as I'm not trying to make these .so files available to
anything that isn't part of the same package build, let alone other
packages on the system.

Still if Fedora forbids rpath, then don't use it for Fedora. They
provide an alternative above, faulty as it may be.

Just don't put anything in the upstream install script that assumes
adding things to /etc/ld.so.conf.d/ is a generally good idea, without
going ahead and doing proper SONAMEing first. If you want to be treated
like a first-class .so file, you have to act like one first.

> http://wiki.debian.org/RpathIssue

"Currently, the only valid use of this feature in Debian is to add
non-standard library path (like /usr/lib/<package>) to libraries that
are only intended to be used by the executables (or other libraries)
within the package."

This is what I'm trying to do.

I've edited the page to make this a seperate paragraph, since you seem
to have missed this on your first reading.

> http://people.debian.org/‾che/personal/rpath-considered-harmful

"The use of the -R or -rpath linker options to hard code a 
dynamic library search path into a binary is considered harmful for
all cases except for a user linking against a library installed
in their own home directory."

Again, this is talking about rpaths to libraries that come with the
operating system. Neither of the issues described here apply to
libraries which _must_ be upgraded along with all their dependants
simultaneously.

This is also talking about rpaths set at 'make install' time to be the
directory being installed into. His description is a little dodgey
though, historically PREFIX works that way, DESTDIR does not, as DESTDIR
is there for redirecting the install location _without_ affecting the
prefix (assumed top-level path).


If it helps you keep the issue clear, pretend private libraries are like
dynamically-loadable modules, not .so files. You wouldn't expect to find
your program's modules in /usr/lib, that'd be daft. You'd have to scan
every file in /usr/lib for the appropriate exported structure to tell
you that it was a module, and hope you were the only program that
thought "struct module_ops" was a good way of telling your modules apart
from random chunks of code.

Instead, you pick module directory (or let the user specificy one) and
assume everything in there that exports a struct module_ops is a module,
exporting _your_ module_ops, and you therefore dlopen it, get the
address of module_ops, and start using the function pointers therein.

That's all we're doing here, except we don't have to use dlopen, we
declare the modules we want at build-time, and ld.so takes that plus our
build-time declared module path, and does the load-time equivalent of
dlopen + filling in the undefined references in the executable.


And in case you think this is academic, FreeRADIUS uses rpath to point
to its modules directory, and then dlopens rlm_[modname].so knowing that
the only way a random could drop rlm_[modname].so into /usr/lib and have
FreeRADIUS use that by accident, is if rlm_[modname].so didn't exist in
the rpath.

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/a717ca74/attachment.pgp