[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Very slow links: > 1 hour to link single executable - can we help?

From: Rob Browning
Subject: Very slow links: > 1 hour to link single executable - can we help?
Date: Wed, 31 Oct 2001 14:48:25 -0600
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1

(After looking at the past few months of this list, I didn't see any
 relevant posts, but if I just overlooked them, please let me know.)

With more recent libtool versions I've noticed suprisingly slow
libtool link times.  After some investigation, I discovered some gnome
related mail discussing the issue that suggested that libtool was
having problems with duplicate libs listed on the link line.

To try and fix this, I used the adapted snippet from gnome-config
listed below to safely remove duplicates from the link line.  This
worked, taking the compiles down from 20 minutes to 10 (this is on a
1GHz Athlon), and this was 

However, since we're about to need to be able to lt_dlopen/dlsym most,
if not all of our libraries, I found that I needed to go back through
and make sure that all of our libs were fully inter-linked.  This
meant more links to each lib's libfoo_la_LIBADD.

After finishing all that, the compile times have jumped way past 20
minutes, to at least more than 90 minutes (as I compose this, the
compile still hasn't finished) -- It looks like duplicates are being
pulled in through the .la files themselves, and I there's no way for
me to clean that up before invoking libtool as I was with the
gnome-config hack.

If I edit our ./libtool file, and add an "set +x", I can see libtool
running some kind of recursive dependency analysis which over hundreds
of iterations builds the deplibs (I think) variable up to pages and
pages of duplicate libs.

If I strace the sh it's runing, I can see that it's trying to stat the
same library, say libm, in many locations, only to turn around and do
that all again.  Right now it has taken over an hour just trying to
link the final executable, and it's still not finished.

My questions:

  1) Is this expected behavior, or are we doing something wrong?
  2) If this is expected, are there plans to fix it?
  3) If there are plans, what can we do to help? :>

Oh, and right now, we're using libtool 1.4.2.



# This script removes any duplicate occurences of -lfoo in its args,
# but preserves the right ordering (last-duplicate-wins) for the
# linker.  Code originally from gnome-config.


# Straight out any possible duplicates, but be careful to
# get `-lfoo -lbar -lbaz' for `-lfoo -lbaz -lbar -lbaz'
for i in $all_flags; do
    case "$i" in
    # a library, save it for later, in reverse order
    -l*|*.la) rev_libs="$i $rev_libs" ;;
        if $libs_L; then
            case " $lib_L_flags " in
            *\ $i\ *) ;;                        # already there
            *) lib_L_flags="$lib_L_flags $i" ;; # add it to output
        case " $other_flags " in
        *\ $i\ *) ;;                            # already there
        *) other_flags="$other_flags $i" ;;     # add it to output
        esac ;;

if $libs_l; then
    for i in $rev_libs; do
        case " $ord_libs " in
        *\ $i\ *) ;;                    # already there
        *) ord_libs="$i $ord_libs" ;;   # add it to output in reverse order

echo $other_flags $lib_L_flags $ord_libs

exit 0

Rob Browning
rlb,, and
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

reply via email to

[Prev in Thread] Current Thread [Next in Thread]