|
|
Boost Testing : |
From: Steve Clamage (Stephen.Clamage_at_[hidden])
Date: 2006-07-03 11:42:16
Yes, this is a known and documented bug in the compiler.
http://developers.sun.com/prodtech/cc/documentation/ss11/mr/READMEs/c++.html#problems
See item #4, Name Mangling Linking Problems
We can't fix this bug without breaking binary compatibility. That is,
code compiled by an old compiler could stop linking if part of the code
was recompiled by a fixed compiler.
For self-contained programs, we provide an undocumented compiler option
that fixes all known bugs in name mangling. This option can be used only
when you can recompile all of the code in an entire program. I can't
recommend this option for BOOST, since many BOOST users must link to
existing binaries.
The README lists a Sun #pragma to work around the problem: create a weak
symbol with the correct mangling that is equated to the symbol with the
wrong mangling.
If you make all declarations for a function identical, you don't run
into the bug.
Fortunately, the incorrect mangling generated by the compiler cannot
ever be a valid mangled name, so all of the workarounds are "safe". That
is, you will never get a situation where a workaround creates a name
collision.
--- Steve Clamage, stephen.clamage_at_[hidden] Douglas Gregor wrote: > Steve, > > I'm CC'ing you on this discussion because it looks like a name > mangling bug in the latest Sun C++ compiler. The linker produces this > error message: > > Undefined???first referenced > symbol ??? in file > const char*boost::date_time::nth_as_str(int) /home/user1/dgregor/ > BoostRegressionTesting/results/boost/bin.v2/libs/date_time/test/ > testfacet_dll.test/sun-5.8/debug/testfacet.o > ld: fatal: Symbol referencing errors. No output written to /home/ > user1/dgregor/BoostRegressionTesting/results/boost/bin.v2/libs/ > date_time/test/testfacet_dll.test/sun-5.8/debug/testfacet_dll > > Grepping for nth_as_str in the library, we see two symbols: > > -bash-2.05b$ nm libboost_date_time-sw58-gd-1_34.so.1.34.0 |grep nth_as_str > 0002628c D $XAsX$TB_yJqEWnE.__1cFboostJdate_timeL_nth_as_str_ > 00013ad8 T __1cFboostJdate_timeKnth_as_str6Fki_pkc_ > > I don't know what that first symbol is, but the second one is clearly > what we want: > > -bash-2.05b$ c++filt > __1cFboostJdate_timeKnth_as_str6Fki_pkc_ > const char*boost::date_time::nth_as_str(const int) > > The problem is that the compiler is putting "const" into the mangled > name for the definition, but it shouldn't be there. > > Jeff, it looks like you can work around this bug by removing "const" > from "const int ele" in src/gregorian/date_generators.cpp. > > Cheers, > Doug > > On Jul 1, 2006, at 12:53 PM, Jeff Garland wrote: > >> >> These failures looks like it might be a setup / Jamfile issue. >> >> http://tinyurl.com/jlm92 >> http://tinyurl.com/r7yt9 >> >> That symbol should be defined in the library. I'm a little rusty on >> my CC >> options, but it looks like the linking options may not be correct -- in >> particular, this looks odd to me: >> >> -Bdynamic -lrt -Bstatic -Bdynamic >> >> Any ideas? >> >> Jeff >> >> _______________________________________________ >> Boost-Testing mailing list >> Boost-Testing_at_[hidden] >> http://lists.boost.org/mailman/listinfo.cgi/boost-testing > >