Hi Al,

On 10/01/2010 12:46 PM, Al wrote:
> The parity compiler sounds very ambitious and I am curious. On the
> other hands I also see the advantages in Microsofts PATH approach.
> Dynamic libraries doen't depend on a special path any more and can be
> moved around. All you have to do, is to adapt the PATH variable to the
> new location. That makes your programs more portable.

While the environment-variable-based approach to find dynamic libraries does
have it advantages indeed, it is a no-go for (automated) package managing.
Use LD_LIBRARY_PATH (and its equivalents) for debugging, playing around,
trying something out, but don't have final binary packages rely on it.
We have been using LD_LIBRARY_PATH&Co in our company for some years, but we
have thrown that away and use the built-into-binaries RPATH/RUNPATH/whatever
approach now, because the environment-variables caused too many headaches:
partially unable to fix at all, or with really bad hacks only.

> What I am pondering on, is a relative RPATH, relative to the prefix
> path. By this the Prefix installation as a whole could still be moved
> around without breaking. You could run a precompiled  PREFIX
> installation out of different user's home directories.

Some of our target platform do support "$ORIGIN" in RPATH&Co.
The problem is that I cannot think of a good way yet to inform prefix'
toolchain about the just linked binary's target location by package's
build systems, which is necessary to calculate an $ORIGIN-based RPATH.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level