[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to lin k
From: |
Rob Browning |
Subject: |
Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to lin k single executable - can we help?] |
Date: |
Mon, 05 Nov 2001 10:50:31 -0600 |
User-agent: |
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 |
"Boehne, Robert" <address@hidden> writes:
> This is a known problem that results from supporting multiple
> dependent archive libraries. In some cases libtool can't strip the
> redundant -lfoo -lbar in dependencies.
Is this because it doesn't know how, or because stripping them would
be bad in some situations (what you say later implies the latter, but
I wanted to be sure), and if stripping duplicates would be bad, why?
If this has been discussed before, and if anyone has a pointer to the
discussion handy, I'd appreciate it.
> I would propose that libtool would strip all duplicate dependencies
> (as it used to do) unless a command line flag is given. I did pose
> this question a few weeks ago but didn't get any response. Time
> permitting, I'll post a patch that would require the KDE developers
> (and others in this situation) to add a flag that preserves all of
> the dependencies when linking. In my project, compile times go from
> 6 hours to infinity. ;) So I've made my own ltmain.sh that won't
> preserve any duplicate dependencies. As soon as I can find the time
> I'll work this into a patch.
Does this help the run-time for the libtool step as well as the link
step? Both of those are a problem here -- /bin/sh takes forever to
compute the list of libs, and then ld takes forever to link them,
balooning up to 480MB during the process!
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD