The reason that strip makes the problem go away is because the "bad" reloc is against the ".debug_info" section, which contains dwarf debugging information. .debug_info and .rel.debug_info both go away when you strip the program.
You can use "dwarfdump -a foo.o" to dump the dwarf information (dwarfdump coms with the Sun Studio compilers). When the GNU linker is used, you might see that the dwarf info which *should* have the address of the symbol .text._ZNSt12domain_errorD0Ev really has either '0' or a small embedded offset instead. I suspect this is the same thing described in: 6407933 dwarf c++ : can't reference comdat local label from non-comdat section I worked around this in our compiler by changing the kind of relocation type. It was somewhat of a pain, but it worked. A much better *design* would be to have all dwarf information pertaining to a COMDAT section group be included as section fragments inside the same section group. That would avoid this problem. But the dwarf format is complicated, the libdwarf generating library is limited in what it can do, and the header overhead for each of the many dwarf sections needed for each section group is sufficient that this is a difficult task. --chris 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 > > > This message posted from opensolaris.org > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org
