[uClibc] [RFC] RUNPATH config option for ld.so

Ivan Popov pin at medic.chalmers.se
Sat Jun 25 13:00:56 UTC 2005


On Sat, Jun 25, 2005 at 02:04:38PM +0200, Joakim Tjernlund wrote:
> > For information, I am routinely doing a lot of work to disable rpaths
> > (with glibc) when compiling applications.
> > As such, I would welcome a feature that makes one independent
> > of configure-s and Makefile-s which sometimes go to extremes for hardwiring
> > rpaths into the resulting files.
> 
> Why do you do this? For security reasons or something else?

Hi Joakim,

rpaths are incompatible with using multiple libraries versions at the same
time. They make sence under the sole prerequisite that there is exactly
one version of each library used at the same time on a system.
As soon as it is not true, they lead to devastating effects.
In a global environment - filesystems shared by all computers
in the world, like Coda, DFS, AFS - it is definitely not true.

The consequence is unmanageable dependency jungle, impossibility
to guarantee correct linking except always recompiling all interdependent
libraries from scratch, at each upgrade of each library.
A nightmare. No, thanks, no rpaths!

(it may be that somebody has researched the implications of rpaths
for scalability, if not, it looks like a proper research topic.
I have learned the consequences the hard way, by being unaware and then
finding myself in a cul-de-sac when libtool "took care" of putting
rpaths in my libraries...)

<background>
One of the basic concepts of Konvalo (konvalo.org) is to disassociate
compilation and configuration - including the actual dynamic libraries
used at runtime.

The separate configuration step implies among others creation of
a wrapper for each "configured instance" of an executable.
The wrapper takes care of runtime linkage and additional configuration
and "personalization" as well, when necessary.

That way one executable can be used in several different "incarnations"
by different users or in different sessions even at the same time.
It makes also library dependencies easily manageable in a global context.

Another very important thing is using the explicit runtime loader of glibc,
which breaks the last compile-time-derived dependency on a certain path
(traditionally common for all executables and as such creating
strong version dependencies over all programs and libraries).
</background>

As said, I am looking forward to using uClibc due to its compactness
and elegancy - as soon as it incorporates the (presumably not a heavy-weight)
feature - a possibility to run the dynamic loader explicitely.
No-rpath option will make my life easier as well, as an additional protection
against occational -rpath at compilation.

Thanks again,
--
Ivan




More information about the uClibc mailing list