openscad: fix build with libc++

[ecronin (Eric Cronin)]

The guard in src/stl-utils.cc assumes that defined(__APPLE__) && defined(__GNUC__) means g++ and libstdc++. To be correct it should be checking for a libstdc++ #define (or the lack of a libc++ #define).

The quick macports fix is on Mavericks (and earlier when configure.stdlib is libc++) patch that file to make the guard false. I'm not sure what the boilerplate we're using for libc++ checks is, and don't have time to look this morning, so no patch provided. CCing Jeremy since he's taken on a lot of the libc++ work in case he has time.

[jeremyhu (Jeremy Huddleston Sequoia)]

The best approach is to just make the code portable, but if that's not possible, this will suffice:

#include <ciso646>
#ifdef _LIBCPP_VERSION
// libc++
#else
// libstdc++
#endif

[mf2k (Frank Schima)]

Replying to jeremyhu@…:

Can you please elaborate how to implement this - ideally in the form of a Portfile patch?

[ecronin (Eric Cronin)]

src/stl-utils.cc has a bad #if, it's what needs patching not the portfile (other than to include the new patchfile in the Portfile).

For ports' purposes, just include the ciso646 header and make defined(__APPLE__) && defined(__GNUC__) be defined(__APPLE__) && defined(__GNUC__) && !defined(_LIBCPP_VERSION) so that with libc++ the file becomes a big noop. That should be able to be applied safely regardless of the compiler/os/stdlib used by macports. Upstream might want to fix it better by explicitly checking for the broken version(s) of gcc or libstdc++ instead of adding on all the things that aren't broken, although a 3rd stdlib for __APPLE__ seems unlikely...

[mf2k (Frank Schima)]

Thanks for the help with this. Finally fixed in r115593. But please let me know if there is a better way.