libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Avoid la files.


From: Duft Markus
Subject: RE: Avoid la files.
Date: Fri, 14 Dec 2007 08:22:34 +0100

Good Morning ;)

Ralf Wildenhues <mailto:address@hidden> wrote:
> * 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)?
> 
> Yes.

Ok, i will try on the Linux box (when the box's owner is here).

> 
>> 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.

On the other hand i don't know if this would lead to anything. Even if
it works with HEAD - i can't go away from 1.5 right now.

> 
>> I attached both the libtool call and the linker call from my w32
>> box, if you wanr i can organize linux output as well.
> 
> Thanks.
> 
> 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?

Those are nearly all libraries that come from us. About 460 libraries
belong to the program directly, and about 300 libraries are part of out
so-called "toolsbox". Most of the libraries that belong to the program
have dependecies among each other, and all have dependencies to toolsbox
libraries (to many of them)

> 
>> 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.

Naa, libtool doesn't need to do anything different from what it is doing
now, it just needs to be faster ;o) Our build tools simply don't know
yet of how to tell libtool to build convenience libraries, but that will
be solved sometimes...

The number of libraries (without convenience libraries) is one of the
little things i really cannot influence ;o( This is the structure of our
software, i'll have to live with that...

> 
> 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. 

Yes, i'm aware of that. BTW on windows this is really fast ;o)

> 
> 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 mentioned therein.

I know how to create shared libs, but this piece of software was never
designed to be shared. Or it was, but somebody missed it *lol*

> 
> 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.

Yes, maybe, but that doesn't change the fact, that the algotithm for
reading .la files has big scalability problems. It would be really cool
if this would be fixed (or i get a patch for this issue), since my
quick-fix for now (commenting it out), also destroys usage of rpath,
since this information is contained in the .la files too.

I found a sed/grep combination, which i rewrote to try things out. This
didn't get me any performance boost. Also i tried linking a smaller
shared libraries with a few (10) objects and a few dependent libraries
(about 20 direct deps, and inderect about 100 deps...). This also has
more or less big performance problems. It takes about 1 minute with .la
reading, and 20 seconds without...

I don't think it should be too hard to reproduce... Just get yourseld
the library with the most dependencies on your system, and try once
normally, and the with lines 2159 through 2172 commented out in
ltmain.sh. This should give a great difference.

> 
>> 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 this...
> 
> 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 your answers.

Whatever you want... ;o) Hope that is enough information.

Cheers, Markus

> 
> Thanks,
> Ralf


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]