This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: RPATH/RUNPATH issue, equivalent to -headerpad on OSX
- From: Michael Hennebry <hennebry at web dot cs dot ndsu dot NoDak dot edu>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: "'Jakub Jelinek'" <jakub at redhat dot com>, "'Alexander Neundorf'" <neundorf at kde dot org>, <binutils at sourceware dot org>
- Date: Thu, 3 Jan 2008 11:22:18 -0600 (CST)
- Subject: 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