This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: RPATH/RUNPATH issue, equivalent to -headerpad on OSX


On Thu, 3 Jan 2008, Dave Korn wrote:

> On 03 January 2008 16:20, Michael Hennebry wrote:
>
>   [Haven't been following the thread but just have a generic point to make:]
>
> > On Thu, 3 Jan 2008, Jakub Jelinek wrote:
>
> >>> This works correctly and convenient, but it takes a lot of time (really a
> >>> lot for big projects).
> >
> > This surprises me.
> > I'd have thought that link time would
> > be small compared to compile time.
>
>   It's a natural assumption, but consider what happens as projects get larger:
>
> - compile time is roughly linear in the number of lines of source code
> (overall/per module)
> - link time (because of having to resolve everything against everything else)
> is quadratic.

Wouldn't binary search bring it down to n log(n)?
Even so, I get the point: n log(n)> n.

>   So when things start scaling up, link time can easily overhaul compile time.
> And that's before you even factor in that use of make and dependency testing
> .c files against .o files means that you don't often have to recompile many
> files of a project most times you build it, whereas the final link always has
> to link the same number of .o/.a files together.

They still have to be compiled at least once.
I was trying to compare the nuisance value of one
more link versus the work done before that link.

If link time really is a major issue,
perhaps there should be some way of caching link
data during a build and discovering when its dirty.

-- 
Michael   hennebry@web.cs.ndsu.NoDak.edu
"I AM DEATH, NOT TAXES.  *I* TURN UP ONLY ONCE."  --  Death


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]