[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoid la files.
Re: Avoid la files.
Thu, 13 Dec 2007 16:51:17 +0100
* Duft Markus wrote on Thu, Dec 13, 2007 at 11:27:34AM CET:
> I'm not sure if i can easily put in HEAD, we use 1.5.24. Would it be
> enough to get HEAD built somewhere, and bootstrap only the last
> component with it (leave all libraries untouched)?
> Maybe we can try on a linux box, w32 won't work, since i don't have my
> patches ported for HEAD ;o(
Yes, that should be sufficient. I can't tell you yet whether it would
help, though, as I'm not yet sure about the actual problem cause.
> I attached both the libtool call and the linker call from my w32 box, if
> you wanr i can organize linux output as well.
So I gather all of those libraries are installed shared libraries that
come from a third-party package? And many of those libraries themselves
depend on other libraries?
> There is not a single convenience library in play, since our tool which
> handles these things (Confix, http://www.sf.net/projects/confix) is
> still not able to produce those things (arg.... I know... We'd really
> need it for our command lines)
I still haven't understood whether this is actually a problem in your
setup/Config/your package, and you want libtool to work around those
limitations, or you *really* need five hundred different shared
libraries and a program that links against all of them.
I mean, wow, have you ever considered that the runtime linker overhead
for this kind of setup can be excessive? Just symbol searching is bound
to take a looong time, and that's even on sane systems like GNU/Linux.
Be kindly advised to consider some general guidance how to create shared
(ELF) libraries: <http://people.redhat.com/drepper/dsohowto.pdf>.
Note also that *fewer* shared libraries is a good thing for the reasons
However, if all those libraries should instead be convenience archives,
because they should just be linked together into one (or a few) big
shared libraries, then you can avoid the libtool performance problems by
simply making those libraries convenience archives.
> The problem i think this command triggers is, that libtool looks at some
> .la files most libraries depend on a lot of times. Maybe caching la
> lookup results would be a solution, although i cannot think of how to do
Hmm, then I may need to look at the full output. But please don't send
it just yet, please just answer the questions above. Don't hesitate to
ask if there is something you don't understand, but please be precise in