Ralf Wildenhues <ralf.wildenh...@gmx.de> writes: > * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST: >> Ralf Wildenhues writes: >> > Provide a configure switch --with-hardcoded-gccdeps that adds run path >> > entries for pre-installed support libraries? >> >> I'm fine with that, but it just introduces another configure option for >> people to learn about. If we have to teach people something, I'd rather >> teach them to use --disable-shared when they build the libraries >> themselves. > > OK. I won't argue my point further, but I am interested to learn why > shared libraries in nonstandard locations are seemingly frowned upon > here. Is that due to fragility of the libtool approach of relinking, > or for relocatability issues of the installed program?
1) We don't use libtool to build gcc. 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. 3) Shared libraries are less efficient. You get some efficiency back if the libraries are in fact shared by multiple different executables running simultaneously. But in this case it is relatively unlikely that gmp, mpfr, and mpc will actually be used by any executable other than gcc. So why make them shared libraries? We lose something, as can be seen by the number of times this has come up in gcc-help. We gain nothing. 4) People sometimes suggest seeing the DT_RPATH/DT_RUNPATH of the executable to point to the shared library locations. Past experience has shown that this is a bad idea for some organizations. Some places mount /usr/local/lib or other directories over NFS. Putting that in DT_RPATH/DT_RUNPATH causes the dynamic linker to search those directories at program startup. That causes startup to be much slower, and can even cause it to hang until the NFS server returns. That is not desirable for the compiler. Ian
