Re: [jamboost] Re: V2: linking complex project with gcc

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-08 10:07:32

Hi Kirill,

> Happy New Year! I hope you'll get a little snow for the holidays. I've
> heard it is kind of warm these days in Moscow...

Thanks! We've had quite nice snowfall started at New Year night and more or 
less continuing since them. Seems like the temperature which was jumping 
around zero for some time finally decided to became negative, so the snow 
even does not melt. 

Anyway... back ontopic ;-)

> >>lib a : a.cpp foo ;
> >
> > Actually, the first declaration says that if you use 'a', you also need
> > to use 'foo'. But it does not say that 'a' uses symbols from 'foo' -- so
> > it's not clear that there are any restriction on relative order on
> > command line.
>
> Well, I see what you mean, but why else would you want to make client to
> link with foo? To be able later on to load some symbols dynamically
> (in case of shared library)? 

Good question. Probably, because in 

lib a : a.cpp : : : <library>foo ;

'a' does not use any symbols from 'foo', but users of 'a' are expected to use 
symbols from 'foo'. I can't come up with a realistic use-case, though. 

I think it's better to wait until we implement link order (if we do). By that 
time, the <library> feature might even disappear ;-)

> Seems to me if we actually decide to
> implement correct ordering of libraries, build system should try, if at
> all possible, to fulfill this kind of dependency as well, but give them
> a lower priority and, probably, do not error out in case of circular
> dependencies within usage requirements.

Oh.. that sounds a bit complex, especially for use-case that we no longer 
officially support. Anyway, we can decide later.

> >>I'll try to do an experiment tonight, measure ld performance in all 3
> >>cases -- libraries in right order, libraries put two times on command
> >>line and -( -). Unfortunately my project is not too big and it might be
> >>hard to see the difference. Any volunteers out there to do similar thing
> >>on their projects?
> >
> > I'd be interested to know your result. I'll also ask on binutils mailing
> > list.
>
> Ok, I performed a quick experiment. I created 3 one line shell scripts,
> first linking almost as bjam currently wants, i.e. all libraries listed
> twice. Almost, because exact command bjam issues, fails for me, so I
> rearranged libraries _a little_, and only rearranged second series of
> libraries. Second shell scripts uses -( -) trick, one set of libraries.
> And thirds shell script is a single series of libraries in correct
> order. I measured them with time command, and added user and systime
> times together. I ran every one of them 5 times, running them in
> following order 1,2,3 1,2,3 and so on 5 times. Average time in seconds is
>
> 6.862, 6.482, 6.246
>
> I.e. current approach the slowest, -( -) is faster, correct order a
> little more faster.
>
> Observed times were vary stable, variation about 0.1-0.2 second.

Thanks for your experiment! This suggests that -( is quite a viable solution.

Jürgen Hunold wrote:
> Hi !
>
> Happy new Year !

And to you too! A bit late, but we in Russia has another New Year on 14th (by 
pre-revolution calendar), so this might serve as excuse ;-)

> Ok. I've done some testing:
>
> Old Libraries specified 2-times
> dynamic:	0m6.167s
> static:	4m15.319s
>
> New:
> dynamic: 0m7.032s
> static:	3m44.356s
>
> dynamic means full dynamic linking
> static means static linked own libraries + qt + 3rd party libs, dynamic
> system. Own libs some 30+, resulting exe 135 mb (release+debug symbols)
> please note the speedup when linking static.
> The most interesting fact is that dynamic liniing time is reduced to 1s
> when everything is in cache (running the same command twice...)

Looks like the performance problems are not an issue. I'll commit the patch as 
soon as possible -- which means, as soon as I fix two test failures with the 
most recent GNU linker.

- Volodya