A question about RPATH

A question about RPATH

[Dennis Clarke]

So for those that look at this list, you all know I am grinding away on trying to get
a nice clean result for GCC 4.7.2 and am somewhat relentless about it.  The very
best I have thus far is this one : 

    http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01762.html

So great, a plate of cookies and some milk for me. 

I was somewhat dismayed when I saw that there was no RPATH in the output elf 
object : 

sedna $ greadelf -d /usr/local/gcc4/bin/x86_64-unknown-linux-gnu-gcc-4.7.2

Dynamic section at offset 0x8b368 contains 23 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libintl.so.8]
 0x0000000000000001 (NEEDED)             Shared library: [libiconv.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x402340
 0x000000000000000d (FINI)               0x43e968
 0x0000000000000004 (HASH)               0x400240
 0x0000000000000005 (STRTAB)             0x401208
 0x0000000000000006 (SYMTAB)             0x4005d8
 0x000000000000000a (STRSZ)              1174 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x68b538
 0x0000000000000002 (PLTRELSZ)           2784 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x401860
 0x0000000000000007 (RELA)               0x4017e8
 0x0000000000000008 (RELASZ)             120 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4017a8
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x40169e
 0x0000000000000000 (NULL)               0x0

This is a problem because of this : 

sedna $ ldd /usr/local/gcc4/bin/x86_64-unknown-linux-gnu-gcc-4.7.2
        linux-vdso.so.1 =>  (0x00007fff0c28e000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x00007f3e08790000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00007f3e084a0000)
        libm.so.6 => /lib64/libm.so.6 (0x00000039fa400000)
        libc.so.6 => /lib64/libc.so.6 (0x00000039fa000000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039f9c00000)

The libs fir libiconv and GNU gettext are in /usr/local/lib and not anywhere to
be found in the system lib areas : 

sedna $ unset LD_LIBRARY_PATH
sedna $ ldd /usr/local/gcc4/bin/x86_64-unknown-linux-gnu-gcc-4.7.2
        linux-vdso.so.1 =>  (0x00007fffd2f20000)
        libintl.so.8 => not found
        libiconv.so.2 => not found
        libm.so.6 => /lib64/libm.so.6 (0x00000039fa400000)
        libc.so.6 => /lib64/libc.so.6 (0x00000039fa000000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039f9c00000)

I am a firm believer that LD_LIBRARY_PATH is evil, certainly at least dangerous and the
output binary from any compile should have an RPATH set to ensure that the correct
libs are found that the developer wanted. 

Having said all that, is there a magic LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing to set to ensure I get my RPATH ?  I should point out this is trivial to do in the Solaris world and perhaps I am missing something really obvious here.

Dennis 

Re: A question about RPATH

[Jim Rice]

> I am a firm believer that LD_LIBRARY_PATH is evil, certainly
> at least dangerous and the
> output binary from any compile should have an RPATH set to
> ensure that the correct
> libs are found that the developer wanted. 
> 
> Having said all that, is there a magic
> LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
> to set to ensure I get my RPATH ?  I should point out
> this is trivial to do in the Solaris world and perhaps I am
> missing something really obvious here.
> 
> Dennis 

crle ?

crle -64 -c /var/ld/64/ld.config -l /lib/64:/usr/lib/64:/usr/local/lib

Re: A question about RPATH

[Dennis Clarke]

> crle ?
> 
> crle -64 -c /var/ld/64/ld.config -l /lib/64:/usr/lib/64:/usr/local/lib

That would also be the wrong way to go here. One need not change the system 
config in order to run a binary. The binary should indicate the preferred path to 
search for libraries within it .. not outside of it. LD_LIBRARY_PATH defeats and wrecks that.

So really the only sane option here is -Wl,--rpath=/usr/local/lib 

Or similar. 

dc

Re: A question about RPATH

[Dennis Clarke]

> > I am a firm believer that LD_LIBRARY_PATH is evil, certainly
> > at least dangerous and the
> > output binary from any compile should have an RPATH set to
> > ensure that the correct
> > libs are found that the developer wanted. 
> > 
> > Having said all that, is there a magic
> > LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
> > to set to ensure I get my RPATH ?  I should point out
> > this is trivial to do in the Solaris world and perhaps I am
> > missing something really obvious here.
> > 
> > Dennis 
> 
> crle ?

The manpage for the linker from binutils looks clear on this matter : 

       -rpath=dir
           Add a directory to the runtime library search path.  This is used
           when linking an ELF executable with shared objects.  All -rpath
           arguments are concatenated and passed to the runtime linker, which
           uses them to locate shared objects at runtime.  The -rpath option
           is also used when locating shared objects which are needed by
           shared objects explicitly included in the link; see the description
           of the -rpath-link option.  If -rpath is not used when linking an
           ELF executable, the contents of the environment variable
           "LD_RUN_PATH" will be used if it is defined.

           The -rpath option may also be used on SunOS.  By default, on SunOS,
           the linker will form a runtime search patch out of all the -L
           options it is given.  If a -rpath option is used, the runtime
           search path will be formed exclusively using the -rpath options,
           ignoring the -L options.  This can be useful when using gcc, which
           adds many -L options which may be on NFS mounted file systems.

           For compatibility with other ELF linkers, if the -R option is
           followed by a directory name, rather than a file name, it is
           treated as the -rpath option.

       -rpath-link=dir
           When using ELF or SunOS, one shared library may require another.
           This happens when an "ld -shared" link includes a shared library as
           one of the input files.

           When the linker encounters such a dependency when doing a non-
           shared, non-relocatable link, it will automatically try to locate
           the required shared library and include it in the link, if it is
           not included explicitly.  In such a case, the -rpath-link option
           specifies the first set of directories to search.  The -rpath-link
           option may specify a sequence of directory names either by
           specifying a list of names separated by colons, or by appearing
           multiple times.

           This option should be used with caution as it overrides the search
           path that may have been hard compiled into a shared library. In
           such a case it is possible to use unintentionally a different
           search path than the runtime linker would do.

           The linker uses the following search paths to locate required
           shared libraries:

           1.  Any directories specified by -rpath-link options.

           2.  Any directories specified by -rpath options.  The difference
               between -rpath and -rpath-link is that directories specified by
               -rpath options are included in the executable and used at
               runtime, whereas the -rpath-link option is only effective at
               link time. Searching -rpath in this way is only supported by
               native linkers and cross linkers which have been configured
               with the --with-sysroot option.

           3.  On an ELF system, for native linkers, if the -rpath and
               -rpath-link options were not used, search the contents of the
               environment variable "LD_RUN_PATH".

           4.  On SunOS, if the -rpath option was not used, search any
               directories specified using -L options.

           5.  For a native linker, the search the contents of the environment
               variable "LD_LIBRARY_PATH".

           6.  For a native ELF linker, the directories in "DT_RUNPATH" or
               "DT_RPATH" of a shared library are searched for shared
               libraries needed by it. The "DT_RPATH" entries are ignored if
               "DT_RUNPATH" entries exist.

           7.  The default directories, normally /lib and /usr/lib.

           8.  For a native linker on an ELF system, if the file
               /etc/ld.so.conf exists, the list of directories found in that
               file.

           If the required shared library is not found, the linker will issue
           a warning and continue with the link.


----

So I will rebuild gcc with LD_RUN_PATH=/usr/local/lib:/usr/local/gcc4/lib64 and see what 
I get. 

Dennis 

Re: A question about RPATH

[Jonathan Wakely]

On 20 December 2012 00:15, Dennis Clarke wrote:
>
>> > I am a firm believer that LD_LIBRARY_PATH is evil, certainly
>> > at least dangerous and the
>> > output binary from any compile should have an RPATH set to
>> > ensure that the correct
>> > libs are found that the developer wanted.
>> >
>> > Having said all that, is there a magic
>> > LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
>> > to set to ensure I get my RPATH ?  I should point out
>> > this is trivial to do in the Solaris world and perhaps I am
>> > missing something really obvious here.

GCC does not tell the linker to set RPATH unless explicitly requested,
see http://gcc.gnu.org/faq.html#rpath

> So I will rebuild gcc with LD_RUN_PATH=/usr/local/lib:/usr/local/gcc4/lib64 and see what
> I get.

That's what I've done when building on Solaris, although in my case it
was for the runtime libs, not the gcc executables (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354#c9). There has been
a suggestion to add a new configure option to set RPATHs, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508#c10

Re: A question about RPATH

[Dennis Clarke]

> On 20 December 2012 00:15, Dennis Clarke wrote:
> >
> >> > I am a firm believer that LD_LIBRARY_PATH is evil, certainly
> >> > at least dangerous and the
> >> > output binary from any compile should have an RPATH set to
> >> > ensure that the correct
> >> > libs are found that the developer wanted.
> >> >
> >> > Having said all that, is there a magic
> >> > LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
> >> > to set to ensure I get my RPATH ?  I should point out
> >> > this is trivial to do in the Solaris world and perhaps I am
> >> > missing something really obvious here.
> 
> GCC does not tell the linker to set RPATH unless explicitly requested,
> see http://gcc.gnu.org/faq.html#rpath

I guess because I tend to enjoy the Linux From Scratch project I like to build a 
compiler which is isolated away from the host operating system that I am
doing the build with. Ultimately I can get a full GNU toolchain in /usr/local
that is self enclosed and will not use libs from /usr/lib etc. 

> > So I will rebuild gcc with 
> LD_RUN_PATH=/usr/local/lib:/usr/local/gcc4/lib64 and see what
> > I get.
> 
> That's what I've done when building on Solaris

I have a good hands on familiarity with Solaris/OpenSolaris and have managed 
to get reasonable toolchains built there. In that case I tend to use LD_OPTIONS 
as well as a few options passed to the compiler to get the desired RPATH.

> although in my case it
> was for the runtime libs, not the gcc executables (see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354#c9). There has been
> a suggestion to add a new configure option to set RPATHs, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508#c10

Well I am all for a RPATH option. 

Dennis 

Re: A question about RPATH

[Dennis Clarke]

> On 20 December 2012 00:15, Dennis Clarke wrote:
> >
> >> > I am a firm believer that LD_LIBRARY_PATH is evil, certainly
> >> > at least dangerous and the
> >> > output binary from any compile should have an RPATH set to
> >> > ensure that the correct
> >> > libs are found that the developer wanted.
> >> >
> >> > Having said all that, is there a magic
> >> > LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
> >> > to set to ensure I get my RPATH ?  I should point out
> >> > this is trivial to do in the Solaris world and perhaps I am
> >> > missing something really obvious here.
> 
> GCC does not tell the linker to set RPATH unless explicitly requested,
> see http://gcc.gnu.org/faq.html#rpath

Well thanbks to the suggestion to use gmake with the -j X for some X>1 as well as the env var LD_RUN_PATH I get a gcc 4.7.2 bootstrapped much faster and with the correct RPATH in it thus : 

sedna $ greadelf -hd ./gcc/xgcc
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x405aa8
  Start of program headers:          64 (bytes into file)
  Start of section headers:          2349040 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         37
  Section header string table index: 34

Dynamic section at offset 0x8b388 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libintl.so.8]
 0x0000000000000001 (NEEDED)             Shared library: [libiconv.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [/usr/local/lib:/usr/local/gcc4/lib64]
 0x000000000000000c (INIT)               0x402360
 0x000000000000000d (FINI)               0x43e988
 0x0000000000000004 (HASH)               0x400240
 0x0000000000000005 (STRTAB)             0x401208
 0x0000000000000006 (SYMTAB)             0x4005d8
 0x000000000000000a (STRSZ)              1211 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x68b568
 0x0000000000000002 (PLTRELSZ)           2784 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x401880
 0x0000000000000007 (RELA)               0x401808
 0x0000000000000008 (RELASZ)             120 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4017c8
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x4016c4
 0x0000000000000000 (NULL)               0x0
sedna $ 

That looks perfect and thus LD_LIBRARY_PATH is not required for this binary to indicate to the runtime linker where the correct libs are. 

sedna $ ldd ./gcc/xgcc
        linux-vdso.so.1 =>  (0x00007fff61dff000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x00007f9387432000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00007f9387142000)
        libm.so.6 => /lib64/libm.so.6 (0x00000039fa400000)
        libc.so.6 => /lib64/libc.so.6 (0x00000039fa000000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039f9c00000)

Thanks to the usage of gmake -j 16 ( yes 16 cores ) I was able to get a result in 
about 73 minutes :

real 4398.04
user 10247.06
sys 1378.21

I will run the testsuite now and hope for a better result than before however I have 
no quantifiable reason to hope for such a thing.  :-)

Dennis 

Re: A question about RPATH

[Andrew Haley]

On 12/19/2012 11:08 PM, Dennis Clarke wrote:
> 
> So for those that look at this list, you all know I am grinding away on trying to get
> a nice clean result for GCC 4.7.2 and am somewhat relentless about it.  The very
> best I have thus far is this one : 
> 
>     http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01762.html
> 
> So great, a plate of cookies and some milk for me. 
> 
> I was somewhat dismayed when I saw that there was no RPATH in the output elf 
> object : 
> 
> sedna $ greadelf -d /usr/local/gcc4/bin/x86_64-unknown-linux-gnu-gcc-4.7.2
> 
> Dynamic section at offset 0x8b368 contains 23 entries:
>   Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: [libintl.so.8]
>  0x0000000000000001 (NEEDED)             Shared library: [libiconv.so.2]
>  0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>  0x000000000000000c (INIT)               0x402340
>  0x000000000000000d (FINI)               0x43e968
>  0x0000000000000004 (HASH)               0x400240
>  0x0000000000000005 (STRTAB)             0x401208
>  0x0000000000000006 (SYMTAB)             0x4005d8
>  0x000000000000000a (STRSZ)              1174 (bytes)
>  0x000000000000000b (SYMENT)             24 (bytes)
>  0x0000000000000015 (DEBUG)              0x0
>  0x0000000000000003 (PLTGOT)             0x68b538
>  0x0000000000000002 (PLTRELSZ)           2784 (bytes)
>  0x0000000000000014 (PLTREL)             RELA
>  0x0000000000000017 (JMPREL)             0x401860
>  0x0000000000000007 (RELA)               0x4017e8
>  0x0000000000000008 (RELASZ)             120 (bytes)
>  0x0000000000000009 (RELAENT)            24 (bytes)
>  0x000000006ffffffe (VERNEED)            0x4017a8
>  0x000000006fffffff (VERNEEDNUM)         1
>  0x000000006ffffff0 (VERSYM)             0x40169e
>  0x0000000000000000 (NULL)               0x0
> 
> This is a problem because of this : 
> 
> sedna $ ldd /usr/local/gcc4/bin/x86_64-unknown-linux-gnu-gcc-4.7.2
>         linux-vdso.so.1 =>  (0x00007fff0c28e000)
>         libintl.so.8 => /usr/local/lib/libintl.so.8 (0x00007f3e08790000)
>         libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00007f3e084a0000)
>         libm.so.6 => /lib64/libm.so.6 (0x00000039fa400000)
>         libc.so.6 => /lib64/libc.so.6 (0x00000039fa000000)
>         /lib64/ld-linux-x86-64.so.2 (0x00000039f9c00000)
> 
> The libs fir libiconv and GNU gettext are in /usr/local/lib and not anywhere to
> be found in the system lib areas : 

The disadvantages of RPATH are well-documented.  Perhaps its usage is
common on Solaris, but we don't much use it on Linux.

Your problem is best solved by installing dependent libraries where
ld.so can find them.  ldconfig can do this, but if these libraries
are available as standard packages that's hugely preferable.

Andrew.

Re: A question about RPATH

[Dennis Clarke]

> > The libs fir libiconv and GNU gettext are in /usr/local/lib and not 
> > anywhere to be found in the system lib areas : 
> 
> The disadvantages of RPATH are well-documented.  

Really?  Name one please. 

> Perhaps its usage is
> common on Solaris, but we don't much use it on Linux.

That would be a weakness then. A long standing standard is that non-vendor supplied software should be installed into /opt with config in /etc/opt and /var/opt etc etc with the vendor names at the end of the path. Much like the way MySQL or Oracle database is installed. The vendor has no reason to rely upon the OS supplier for libraries however they may choose to. Therefore a vendor of software that has concern for quality and control of the users expected results will generally provide the libs required also and they will be in the directories such as /opt/foo/lib for example. The binaries will therefore have a RPATH set to use the libs from the software vendor and thus isolate the expected software results into a region of control that the software vendor can respond to. 

The usage of the new defacto /usr/local is a new concept and seems to work fine within the Linux world however Red Hat is very far behind on version releases for many things, therefore I build my own dependecies and then ensure that with -Wl,-rpath=/usr/local/lib or similar I can isolate my software from the Red Hat versions. 

> Your problem is best solved by installing dependent libraries where
> ld.so can find them. 

Yes and no. Again I could argue the point from the perspective of control and quality. If I rely upon the software from the OS supplier ( Red Hat, Debian, Oracle ) then I must assume that the OS vendor is on top of things and provides reasonably up to date software that addresses security and feature concerns. This is rarely the case and the trade off between stability and feature rich end user tools is always a tough balance. I therefore choose to build what I want and isolate it from the OS vendor. 

>  ldconfig can do this, but if these libraries
> are available as standard packages that's hugely preferable.

to whom ? 

Dennis 

Re: A question about RPATH

[Andrew Haley]

On 12/20/2012 11:01 AM, Dennis Clarke wrote:
> 
> 
>>> The libs fir libiconv and GNU gettext are in /usr/local/lib and not 
>>> anywhere to be found in the system lib areas : 
>>
>> The disadvantages of RPATH are well-documented.  
> 
> Really?  Name one please. 

Certainly not.  It would be way off-topic, and it's controversial and
inflammatory.  Suffice it to say that the non-usage of RPATH is
deliberate, and has been considered at length.

>> Your problem is best solved by installing dependent libraries where
>> ld.so can find them. 
> 
> Yes and no. Again I could argue the point from the perspective of
> control and quality. If I rely upon the software from the OS
> supplier ( Red Hat, Debian, Oracle ) then I must assume that the OS
> vendor is on top of things and provides reasonably up to date
> software that addresses security and feature concerns.

Well, yes.  But that has no bearing on making ld.so aware of where
you've put your libraries.

> This is rarely the case and the trade off between stability and
> feature rich end user tools is always a tough balance. I therefore
> choose to build what I want and isolate it from the OS vendor.

Your call.

>> ldconfig can do this, but if these libraries are available as
>> standard packages that's hugely preferable.
> 
> to whom ? 

Perhaps not to you.  I'm not going to argue with you.  gcc-help is not
for such things.

If you really want to build your gcc binaries with RPATH, you can do
that.

Andrew.

Re: A question about RPATH

[Jonathan Wakely]

On 20 December 2012 09:42, Andrew Haley wrote:
>
> The disadvantages of RPATH are well-documented.  Perhaps its usage is
> common on Solaris, but we don't much use it on Linux.

Speak for yourself. Linux distros might not, but that doesn't mean users don't.

As I said at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354#c9
"Whether you think LD_LIBRARY_PATH is more or less evil than RPATH is
your business, but I want to be able to make my own decision."

> Your problem is best solved by installing dependent libraries where
> ld.so can find them.  ldconfig can do this, but if these libraries
> are available as standard packages that's hugely preferable.

If I deploy code releases to dozens of production machines in
~produser/rel/appname/ver_x.y, at least once a week, should I keep
updating ld.so.conf to add ~produser/rel/appname/ver_x.y/lib for every
new appname/rel.x.y, and remove the paths to the older releases as
they get deleted off the boxes?  Or should I simply put executables in
~produser/rel/appname/ver_x.y/bin with RPATH=$ORIGIN/../lib and their
library dependencies in ~produser/rel/appname/ver_x.y/lib?  Using
RPATH with $ORIGIN ensures the right libs are found for a given
executable. The makefiles that build the code ensure
-Wl,-rpath,$ORIGIN/../lib is used and that's all that's needed, the
libraries will be found with no extra work, wherever they get
deployed, as long as the libs stay in ../lib relative to the exes..
Even if NFS was involved (it isn't) if the executables can be reached
then so can the libs, as they're on the same partition.
LD_LIBRARY_PATH would need to be constantly set to something different
if I want to use ~produser/rel/app1/ver_1.2 and
~produser/rel/app1/ver_1.3 and ~produser/rel/app2/ver_3.4 all at once,
let alone run multiple versions of the code in a dev or UAT env to
test and compare results. By using an RPATH containing $ORIGIN all
this can be done with only privs to write to ~produser, not superuser
privs or sudo access to ld.so.conf

ld.so obviously works best for packagers such as distros, or if people
deploying software to production have root access, or if you only have
one version of a library that all executables on the box want to use,
but RPATH is extremely useful for other (IMHO important) uses.

Rant over ;)

Re: A question about RPATH

[Andrew Haley]

On 12/20/2012 11:40 AM, Jonathan Wakely wrote:
> On 20 December 2012 09:42, Andrew Haley wrote:
>>
>> The disadvantages of RPATH are well-documented.  Perhaps its usage is
>> common on Solaris, but we don't much use it on Linux.
> 
> Speak for yourself. Linux distros might not, but that doesn't mean users don't.
> 
> As I said at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354#c9
> "Whether you think LD_LIBRARY_PATH is more or less evil than RPATH is
> your business, but I want to be able to make my own decision."

You can do that with your gcc installation.  The only question here is
the default.

Andrew.