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