Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 06:35:38PM +0200, Daniel Kobras wrote:
> On Tue, Oct 14, 2003 at 11:57:40AM -0400, Daniel Jacobowitz wrote:
> > On Tue, Oct 14, 2003 at 10:38:49AM +0200, Daniel Kobras wrote:
> > > On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> > > > I really feel we should get rid of all these static libraries. Who uses
> > > > static linking now that even our glibc doesn't support it correctly
> > > > across versions?
> > >
> > > People who want their binaries to run across different Linux machines.
> >
> > Dynamic linking to an old version of glibc is more portable than
> > statically linking to any version. Exhibit A is NSS; exhibit B is
> > iconv. Neither works properly when statically linked unless run
> > against the exact same glibc version.
>
> The sentence I refer to reads: 'I really feel we should get rid of all
> these static libraries.' _All_ static libraries. glibc is quite special
> in this regard because it's likely to be present even on a minimalist
> system.
>
> > > People who need to minimize startup times.
> >
> > Static linking does _not_ minimize startup times; in fact it's quite
> > inefficient. Dynamic linking + prelinking is much faster if you care
> > about startup times.
>
> Prelinking is also quite recent and not yet available on any platform as
> far as I know. Are you claiming that startup performance of statically
> linked objects is equal to shared objects even without prelink?
Often worse, due to the dramatically increased amount of data which
must be loaded from disk in a cold-cache situation. Another 800K of
glibc you've got to read in. The memory usage sucks too.
Prelinking is now available on almost all Debian architectures, so I'm
not sure what you mean.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: