Recent compilation troubles with gcc atomics
Hello all, Recently I have noted more than one posting to this list with regards to compilation troubles on some platforms utilizing Gnu C++ or Intel's C++ compiler. Specifically, I am referring to linking errors with some of gcc's internal `atomics' functions, e.g. `__sync_fetch_and_add'. Some searching brings up: http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg197119.ht... http://www.nabble.com/Building-for-ARM926EJ-S-td16447579.html http://groups.google.com/group/boost-list/browse_thread/thread/8e757cc2788d5... https://svn.boost.org/trac/boost/ticket/2525 http://www.nabble.com/issues-with-unit-tests-on-intel-32-bit,-gcc-4.3,-undef... I also happen to follow the libstdc++ mailing list, which has just seen an elucidating post by Joseph S. Myers: http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html In it, he notes that the availability of these builtins is not solely a function of the compiler version. In particular, the platform (CPU, OS, runtime support) seems to be a factor, as well as the backend code generation options (i.e. -march gcc compiler option). He also suggests that the only reliable methodology for discovering the availability of these functions/builtins is by doing link-time tests. I mention as much because (unverified) I think boost's current solution is #ifdefs based on architecture and compiler version, which I think is fighting a losing battle. I hope this information is useful for those stuck on the problem, and/or boost developers. Cheers, -tom
participants (1)
-
tom fogal