* A question about RPATH @ 2012-12-19 23:08 Dennis Clarke 2012-12-19 23:21 ` Jim Rice 2012-12-20 9:42 ` Andrew Haley 0 siblings, 2 replies; 12+ messages in thread From: Dennis Clarke @ 2012-12-19 23:08 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-19 23:08 A question about RPATH Dennis Clarke @ 2012-12-19 23:21 ` Jim Rice 2012-12-19 23:57 ` Dennis Clarke 2012-12-20 0:15 ` Dennis Clarke 2012-12-20 9:42 ` Andrew Haley 1 sibling, 2 replies; 12+ messages in thread From: Jim Rice @ 2012-12-19 23:21 UTC (permalink / raw) To: gcc-help, 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 ? crle -64 -c /var/ld/64/ld.config -l /lib/64:/usr/lib/64:/usr/local/lib ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-19 23:21 ` Jim Rice @ 2012-12-19 23:57 ` Dennis Clarke 2012-12-20 0:15 ` Dennis Clarke 1 sibling, 0 replies; 12+ messages in thread From: Dennis Clarke @ 2012-12-19 23:57 UTC (permalink / raw) To: Jim Rice; +Cc: gcc-help > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-19 23:21 ` Jim Rice 2012-12-19 23:57 ` Dennis Clarke @ 2012-12-20 0:15 ` Dennis Clarke 2012-12-20 0:19 ` Jonathan Wakely 1 sibling, 1 reply; 12+ messages in thread From: Dennis Clarke @ 2012-12-20 0:15 UTC (permalink / raw) To: Jim Rice; +Cc: gcc-help > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 0:15 ` Dennis Clarke @ 2012-12-20 0:19 ` Jonathan Wakely 2012-12-20 0:31 ` Dennis Clarke 2012-12-20 2:26 ` Dennis Clarke 0 siblings, 2 replies; 12+ messages in thread From: Jonathan Wakely @ 2012-12-20 0:19 UTC (permalink / raw) To: Dennis Clarke; +Cc: Jim Rice, gcc-help 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 0:19 ` Jonathan Wakely @ 2012-12-20 0:31 ` Dennis Clarke 2012-12-20 2:26 ` Dennis Clarke 1 sibling, 0 replies; 12+ messages in thread From: Dennis Clarke @ 2012-12-20 0:31 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jim Rice, gcc-help > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 0:19 ` Jonathan Wakely 2012-12-20 0:31 ` Dennis Clarke @ 2012-12-20 2:26 ` Dennis Clarke 1 sibling, 0 replies; 12+ messages in thread From: Dennis Clarke @ 2012-12-20 2:26 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jim Rice, gcc-help > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-19 23:08 A question about RPATH Dennis Clarke 2012-12-19 23:21 ` Jim Rice @ 2012-12-20 9:42 ` Andrew Haley 2012-12-20 11:01 ` Dennis Clarke 2012-12-20 11:40 ` Jonathan Wakely 1 sibling, 2 replies; 12+ messages in thread From: Andrew Haley @ 2012-12-20 9:42 UTC (permalink / raw) To: Dennis Clarke; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 9:42 ` Andrew Haley @ 2012-12-20 11:01 ` Dennis Clarke 2012-12-20 14:51 ` Andrew Haley 2012-12-20 11:40 ` Jonathan Wakely 1 sibling, 1 reply; 12+ messages in thread From: Dennis Clarke @ 2012-12-20 11:01 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc-help > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 11:01 ` Dennis Clarke @ 2012-12-20 14:51 ` Andrew Haley 0 siblings, 0 replies; 12+ messages in thread From: Andrew Haley @ 2012-12-20 14:51 UTC (permalink / raw) To: Dennis Clarke; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 9:42 ` Andrew Haley 2012-12-20 11:01 ` Dennis Clarke @ 2012-12-20 11:40 ` Jonathan Wakely 2012-12-20 14:54 ` Andrew Haley 1 sibling, 1 reply; 12+ messages in thread From: Jonathan Wakely @ 2012-12-20 11:40 UTC (permalink / raw) To: Andrew Haley; +Cc: Dennis Clarke, gcc-help 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 ;) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A question about RPATH 2012-12-20 11:40 ` Jonathan Wakely @ 2012-12-20 14:54 ` Andrew Haley 0 siblings, 0 replies; 12+ messages in thread From: Andrew Haley @ 2012-12-20 14:54 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Dennis Clarke, gcc-help 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-12-20 14:54 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-12-19 23:08 A question about RPATH Dennis Clarke 2012-12-19 23:21 ` Jim Rice 2012-12-19 23:57 ` Dennis Clarke 2012-12-20 0:15 ` Dennis Clarke 2012-12-20 0:19 ` Jonathan Wakely 2012-12-20 0:31 ` Dennis Clarke 2012-12-20 2:26 ` Dennis Clarke 2012-12-20 9:42 ` Andrew Haley 2012-12-20 11:01 ` Dennis Clarke 2012-12-20 14:51 ` Andrew Haley 2012-12-20 11:40 ` Jonathan Wakely 2012-12-20 14:54 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).