http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-15 20:06:55 UTC --- (In reply to comment #34) > (In reply to comment #32) > > I'm not sure -march=i386 explains the original report, since the OP said his > > compiler command was: > > > > $ g++ -std=c++0x -pthread thread.cc -o thread > > > > Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you > > compile > > with (implicit or explicit) march=i386 ? > > If not, the library will think it can use builtins which aren't available. > > I > > seem to recall known issues arising from mismatches in -march options used > > when > > building and using the library. > > Maybe by default, his gcc installation/configuration builds i386 (or some > other > arch that has the same problem even), and it didn't seem relevant to mention. > I'm unsure how gcc determines its default, but that seems a likely scenario to > me. But in that case the library would have been configured and built with the same option, so every thing should match. > And I can reproduce it by explicitly specifying i386, so I'm inclined to think > this is the case. Yes, but then you have a mismatch between the already built libstdc++.so and the new objects you link to it. I'm not saying you're wrong, just that it *should* to work if you configure and build for the exact same target. It's less surprising (though still not good) if things fail when you mix'n'match, basically because i386 is crippled compared to other x86 targets.
