A question about RPATH

[Dennis Clarke <dclarke at blastwave dot org>]

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