1 |
Hi Al, |
2 |
|
3 |
On 10/01/2010 12:46 PM, Al wrote: |
4 |
> The parity compiler sounds very ambitious and I am curious. On the |
5 |
> other hands I also see the advantages in Microsofts PATH approach. |
6 |
> Dynamic libraries doen't depend on a special path any more and can be |
7 |
> moved around. All you have to do, is to adapt the PATH variable to the |
8 |
> new location. That makes your programs more portable. |
9 |
|
10 |
While the environment-variable-based approach to find dynamic libraries does |
11 |
have it advantages indeed, it is a no-go for (automated) package managing. |
12 |
Use LD_LIBRARY_PATH (and its equivalents) for debugging, playing around, |
13 |
trying something out, but don't have final binary packages rely on it. |
14 |
We have been using LD_LIBRARY_PATH&Co in our company for some years, but we |
15 |
have thrown that away and use the built-into-binaries RPATH/RUNPATH/whatever |
16 |
approach now, because the environment-variables caused too many headaches: |
17 |
partially unable to fix at all, or with really bad hacks only. |
18 |
|
19 |
> What I am pondering on, is a relative RPATH, relative to the prefix |
20 |
> path. By this the Prefix installation as a whole could still be moved |
21 |
> around without breaking. You could run a precompiled PREFIX |
22 |
> installation out of different user's home directories. |
23 |
|
24 |
Some of our target platform do support "$ORIGIN" in RPATH&Co. |
25 |
The problem is that I cannot think of a good way yet to inform prefix' |
26 |
toolchain about the just linked binary's target location by package's |
27 |
build systems, which is necessary to calculate an $ORIGIN-based RPATH. |
28 |
|
29 |
/haubi/ |
30 |
-- |
31 |
Michael Haubenwallner |
32 |
Gentoo on a different level |