List Archive: gentoo-alt
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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.
Gentoo on a different level