View Bug Activity | Format For Printing
This bug occurs with the binutils-060823 snapshot and binutils-2.16.91.0.6-5 (fedora-5) on both x86-64 and i386 architectures. It do not occur with binutils-2.15.94 (fedora-4). When linking C++ files compiled by GCC 4.1.1 with the -g option ld take 3 minutes to link . Without the -g option the link time was 5 seconds. The obtained shared library has 17 MBytes size without debugging symbols and 59 MBytes size with debugging symbols.
Created an attachment (id=1243) gprof execution profile of ld This is the gprof call graph profile data of ld (binutils-060823 ) linking the files with the dwarf2 symbols.
Please try the current Linux binutils at http://www.kernel.org/pub/linux/devel/binutils/ and follow its release note closely.
I have installed the latest binary rpm package binutils-2.17.50.0.3-1.x86_64.rpm. With this version, the link time was 6m20.613s with the debugging symbols. Without the debugging symbols, the link time was 4.369s.
Are you sure that you used the correct linker?
Is this the same bug as in commect #9 in PR 2342: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2342#c9
I think this bug is the same as the one in comment #9 of PR 2342. With binutils 2.17.50.0.3 (linux patch applied) and the given test case slowld.tar.gz the link time was 2m54.853s. After removing the debugging symbols with 'strip -g' the link time become 6.386s. I have another test case at ftp://www.smr.ch/pub/smr/read/slow_ld_testcase.tar.bz2 with seven elf64 object files where the link time was 1m7.316s with debugging symbols but 0.926s after a 'strip -g *.o'.
They are 2 different problems. With the previous patch, I got 18 sections: time g++ -B/export/home/hjl/usr/bin/ -g -o ff3d trapFPE.o main.o FFThread.o StaticCenter.o \ language/libfflanguage.a solver/libffsolve.a \ language/libpovlanguage.a geometry/libffgeometry.a \ algebra/libffalgebra.a utils/libffutils.a -pthread FFThread.o: In function `FFThread::run()': /space/rguenther/src/c++bench/ff3d/FFThread.cpp:79: undefined reference to `__cxa_get_exception_ptr' StaticCenter.o: In function `LagrangianFiniteElement': ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' StaticCenter.o:./solver/LagrangianFiniteElement.hpp:365: more undefined references to `__cxa_get_exception_ptr' follow collect2: ld returned 1 exit status Command exited with non-zero status 1 18.32user 1.60system 0:19.92elapsed 100%CPU The other problem is the N^2 issue mentioned in the previous bug report. It is the same as this one. I posted a patch at http://sourceware.org/ml/binutils/2006-08/msg00334.html
I have done some testing on this problem: link time just before http://sourceware.org/ml/binutils-cvs/2004-07/msg00124.html: real 0m8.783s user 0m8.049s sys 0m0.628s After: real 13m49.449s user 12m57.109s sys 0m8.897s current CVS: real 3m52.577s user 3m43.602s sys 0m8.665s current CVS + proposed patch: real 0m5.780s user 0m3.528s sys 0m0.596s Why the proposed patch wasn't committed? I am not familiar with binutils, but maybe I can help.
ld´s changelog of 2.17.50.0.3 (or 4...) binutils says that this patch is applied, but in fact it isn´t, as this version is still affected by this bug. The patch can´t be seen in cvs either. IMO this is a major bug, the difference between linking with and without -g is absurd... we can get from 6min to 30s just by removing -g... Someone please commit the patch to cvs please.
Please follow the release note of the Linux binutils 2.17.50.0.5. You need to apply patches in patches PROPERLY. Or you should use binary rpmes.
*** Bug 3321 has been marked as a duplicate of this bug. ***
http://sourceware.org/ml/binutils/2006-08/msg00334.html is checked in. The maining one is http://sourceware.org/ml/binutils/2006-04/msg00329.html
Caching implemented in http://sources.redhat.com/ml/binutils/2006-11/msg00190.html