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
 
 
This message posted from opensolaris.org

Reply via email to