Trouble doing bootstrap
Ralf Wildenhues
Ralf.Wildenhues@gmx.de
Thu Oct 14 19:19:00 GMT 2010
* 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.
More information about the Gcc
mailing list