[Top][All Lists]

[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: Thu, 13 Dec 2007 11:27:34 +0100


W32 was the fastest with 40 minutes, a x86_64 linux that i tried as well
took about 50 minutes before we canceled ;o(

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

I attached both the libtool call and the linker call from my w32 box, if
you wanr i can organize linux output as well.

There is not a single convenience library in play, since our tool which
handles these things (Confix, is
still not able to produce those things (arg.... I know... We'd really
need it for our command lines)

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

P.S.: the attached output has the .la searching commented out.. If you'd
need the outher output, you will have to wait a hour or two ;o) We have
two executables, both link looots of libraries, i attached both's

P.P.S.: we recently changed Confix (see above) to include all dependent
libraries on the command line, because there are some weird implicit
dependencies around, which didn't get resolved otherwise... Arg - again

P.P.P.S.: please ignore the warnings in the output, they're fixed
already ;o)

And thanks for the fast reaction... ;o)

Cheers, Markus

Ralf Wildenhues <> wrote:
> Hello Markus,
> Thanks for the report.
> * Duft Markus wrote on Thu, Dec 13, 2007 at 10:34:16AM CET:
>> I have a quick question about libtool: What can I break, if I fool
>> libtool into thinking that there are no .la files for any library on
>> the command line? 
>> The background: We have a bunch of software (about 1000 libraries)
>> which are linked (shared) together in one executable. If manually
>> linking it takes about 30 seconds. If linking with libtool it takes
>> 40 minutes.... You see the problem? If I just comment out the double
>> loop in libtool at line (approximately) 2517 and set found=no
>> allways, it takes only 36 seconds.
> Which Libtool version?  If branch-1-5, can you try out with HEAD as
> well?  Are those 1000 libraries all convenience archives?  Can you
> post the link command line and the output that libtool generates from
> it? Are those 40 minutes on w32 or some other system as well?
> To be able to help I need to be able to reproduce the scalability
> issue. 
> Cheers,
> 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

Attachment: linkout.tgz
Description: linkout.tgz

reply via email to

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