Gentoo Archives: gentoo-alt

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] Stating officially with Cygwin
Date: Mon, 04 Oct 2010 07:09:40
Message-Id: 4CA97DA0.9020104@gentoo.org
In Reply to: Re: [gentoo-alt] Stating officially with Cygwin by Al
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