> 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
