Hi All, I bumped into a problem that others have seen previously and I _think_ I found the problem...
Certain c++ apps fail to build on sparc with the 'undefined symbol __sync_fetch_and_add4' error. It seems that this may be due to the way gcc was packaged for sparc. If we look through the headers for __sync_fetch_and_add, we find: include/c++/4.3.3/ext/atomicity.h (and a few others) This file defines __exchange_and_add using __sync_fetch_and_add if _GLIBCXX_ATOMIC_BUILTINS is defined. This value is defined as 1 in: include/c++/4.3.3/sparc-sun-solaris2.8/bits/c++config.h include/c++/4.3.3/sparc-sun-solaris2.8/sparcv9/bits/c++config.h Looking in include/c++/4.3.3/sparc-sun-solaris2.8/, we have only bits/ and sparcv9/. As sparcv9 supports the required atomic operations but sparcv8 doesn't (according to my reading, correct me if I'm wrong), I hypothesize that the architecture detection done during the gcc4 build picked up the fact that it was building on a sparcv9 and set values accordingly. Thus, even when building things with flags forcing sparcv8, gcc thinks it can use capabilities that it can't. Does this all sound reasonable? If this is the case, we should likely have gcc4 rebuilt with different flags so that it's base is v8. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
