* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 08:43:51PM CEST: > Ralf Wildenhues writes: > > 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.
I know. That's easily "fixed" though.[1] Whether one uses the tool or reinvents or reuses part of the functionality is a different question than whether some functionality itself is desirable or not, however. > 2) If we did use libtool to build gcc, then, yes, I would be concerned > about the relinking issue. Why? Because of 'make install' run as root? Any other reasons? > 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. It is not so unlikely that multiple instances of cc1, cc1plus, and f951 are running simultaneously. Granted, I haven't done any measurements. > 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. Well, we *could* make hardcoding the default in order to cope with gcc-help.[2] > 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. Good points. Thanks, Ralf [1] I'll hope you'll excuse me playing devil's advocate here. ;-) [2] Oops. Twice in one message.
