Re: Hardcoding of .la file paths in .la files
On Tue, Oct 14, 2003 at 07:44:05PM +0200, Daniel Kobras wrote:
> On Tue, Oct 14, 2003 at 12:48:28PM -0400, Daniel Jacobowitz wrote:
> > 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.
>
> That's glibc. It's already in memory. This is not necessarily the case
> for less widespread libs. Depending on the contents of the .a, and the
> number of functions actually used, you might end up reading in less data
> from disk, and also save on filesystem and dynamic symbol lookup. I'm
> not advocating to link in glibc statically. I'm advocating to leave it
> up to the users to pick their preferred method of linking, and not put
> up extra hurdles.
Sure, if you statically include individual libraries this isn't an
issue. The result is a dynamically linked application with no
dependency on that library, however. .la files will _NOT_ help you do
this. I don't think libtool can even grasp the idea.
> > Prelinking is now available on almost all Debian architectures, so I'm
> > not sure what you mean.
>
> I'm referring to
>
> % apt-cache showsrc prelink | grep Architecture
> Architecture: alpha i386 powerpc
>
> I'm glad to hear that support for further architectures is apparently
> getting along. Still, this whole prelink issue is tangent to the main
Ask the prelink package maintainer why the heck that's so. It also
works on (offhand) SH, ARM, ia64, s390, s390x, powerpc64, x86-64. I
don't know about m68k or hppa. MIPS is a holdout. It works, in other
words, nearly everywhere. This information is months old.
> point: There are valid reasons for static linking, and I oppose the
> blanket statement that we should deprecate this method.
I agree with you that it shouldn't be deprecated, as I said at the
beginning. Sorry if I gave any different impression.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: