Andrew, If you are interested in COMDAT in gcc on Solaris sparc, you can check out the 'GCC for SPARC Systems' at http://cooltools.sunsource.net. It uses Solaris COMDAT and is based on gcc 4.0.2.
Chih-Hung Hsieh Andrew C. Morrow wrote: >On a recently patched Solaris 10 x86 system I built a gcc-4.2 snapshot, using >the recommended > >--with-gnu-as >--with-as=path-to-gnu-as >--without-gnu-ld >--with-ld=/usr/ccs/bin/ld > >mixed toolchain setup. The resulting compiler would generate shared objects >that exhibited the issue described here: > >http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6354160 > >In effort to work around 6354160, I tweaked the gcc 4.2 snapshot configure >script so that it would detect that the solaris linker supported hidden and >group COMDAT (which it does, according to the docs). Using COMDAT to discard >symbols seems better to me than relying on the linkonce naming convention, and >if I can get it to work I would like to add support for COMDAT on Solaris to >gcc. > >However, building the modified compiler failed when it tried to build the GNU >C++ runtime library libstdc++.so. Using a pared down version of the link line, >here is an example error: > >/usr/ccs/bin/ld -G .libs/functexcept.o .libs/stdexcept.o -o /tmp/libfizzle.so >ld: fatal: relocation error: file: .libs/stdexcept.o section: .rel.debug_info >symbol: : relocation against a discarded symbol, > symbol is part of discarded section: .text._ZNSt12domain_errorD0Ev > >Now, these objects do link when using the GNU binutils linker: > >/usr/sfw/bin/gld -shared --allow-shlib-undefined .libs/functexcept.o >.libs/stdexcept.o -o /tmp/libfizzle.so > >generates libfizzle.so just fine. They will also link with the Solaris linker >if the objects are first stripped, which is interesting. > >Looking around on sunsolve for information about COMDAT I found bug 6407933 >which looks very similar: COMDAT and dwarf output from the Sun C++ compiler, >and it fails with a nearly identical error. > >So is the Solaris linker correct to complain here, and there is something >malformed in these object files? Or is the linker being too conservative when >dealing with relocations against discarded symbols, where the symbol has been >discarded in favor of another equivalent (size/signature) definition? The GNU >linker seems to handle this as a special case. Or am I totally off on the >wrong path here? > >I can provide copies of functexcept.o and stdexcept.o generated from my broken >GCC build if that is helpful. > >Thanks, >Andrew > > > >
