With the -g option, the C++ compiler turns off front-end inlining and generates out-of-line function bodies for inline functions. This also ends up creating many many extra relocations for those extra calls.
Try compiling with the -g0 (gee zero) option and see if that improves the performance. That has the same effect as -g without affecting front-end inlining. --chris Ken Cox wrote: > I have a shared library that takes more than 20 minutes to link on Solaris. > The same link on Linux takes a mere 4-5 minutes; on Windows, the link is 15 > seconds. The delay is becoming unbearable. What should I try next? Here's > some background and what I've tried. > > The link process goes like this: > > cd dir1 ; CC -c -KPIC *.cpp ; ld -o libdir1.o *.o > cd dir2 ; CC -c -KPIC *.cpp ; ld -o libdir2.o *.o > ... > CC -G -z text -dy -B symbolic -g -pta -KPIC -o libmucho.so \ > libdir*.o libssl.a libcrypto.a -l... > > It's the last 'CC -G' that takes 20 minutes. I can't say why we use 'ld -r' > to build intermediate objects. > > Here's what I've tried: > > 1) Using Sun Studio 10 (2005-06-13) instead of Workshop 60U2, Solaris 10 > instead of Solaris 8. > --> Still takes 20 min. > > 2) Putting all files on local disk instead of the Netapp filer. > --> Still takes 20 min. 'truss -cf CC ...' indicates the time spent is > all user CPU. > > 3) Removing -Bsymbolic. > --> Still takes 20 min. > > 4) Linking optimized objects instead of debug. > --> 4 minutes. > > So far the only reasonably performing link seems to be the optimized link. > Where should I look next? I have read and considered the guidelines in the > Linker guide, e.g. getting rid of global interfaces, but that is an expensive > proposition, and before I undertake something like that, I would rather have > a clue as to whether it will reap any benefits. > > Thanks for any insights, > Ken Cox > This message posted from opensolaris.org > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org
