RPATH/RUNPATH issue, equivalent to -headerpad on OSX

Michael Hennebry hennebry@web.cs.ndsu.NoDak.edu
Fri Jan 4 15:15:00 GMT 2008

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

More information about the Binutils mailing list