On Feb 24, 2010, at 12:13 AM, Wolf Drechsel wrote:
As far as I understood the whole thing, the basic problem is a bug in Apple's gcc4.0.1. Wouldn't it be the smartest fix to switch over to a more recent compiler - which may bare some more advantages (such as improved AltiVec and multiprocessor support)?
Well, that was more of the immediate symptom, not the real problem.
The basic problem is that a developer changed code to use some feature that is not supported on all target platforms. This is actually a common occurrence, and there are many standard tools and approaches for this. That is much of what autotools provides for us. Inkscape has been successfully handling such cases for years.
Autoconf will check for each library, tool, feature and bug that might be pertinent, then configures things to compensate for that. Thus it simplifies the problem to one that allows a single source distribution of a piece of software to be built successfully on a large range of targets.
Even better in this case is that we're not the only one who has seen this issue. First we have autoconf just detect/test and then set HAVE_HASH_SET, HAVE_UNORDERED_SET, or HAVE_TR1_UNORDERED_SET. Then
#if defined(HAVE_TR1_UNORDERED_SET) #include <tr1/unordered_set> #elif defined(HAVE_UNORDERED_SET) #include <unordered_set> #elif defined(HAVE_HASH_SET) #include <ext/hash_set> #endif
Of course, to avoid needing boilerplate everywhere a solution usually tosses those into a single .h file that is included instead of <tr1/unordered_set>, etc. Add a dash of typedef magic and you now have robust source code that is actually portable.