Suggested fixes for `variant.h` about oxen-encoding

[jagerman]

Does the gcc build use its own stdlibc++, or is it using the system libc++? (The problem is specific to AppleClang + apple's oft-broken libc++).

[jagerman]

In theory, #if defined(__APPLE__) && defined(__clang__) && defined(_LIBCPP_VERSION) might be enough here.

[barracuda156]

@jagerman GCC normally (by default) uses libstdc++.

For clang, it may work with libc++, but we will need to use LLVM clang with a newer runtime libs, and I am not sure how to write a logic via macros for that.
(I know how to write the logic for compiler and runtime choice in the portfile, but can test it a bit later. GCC works fine though, that is tested.)

[barracuda156]

In theory, #if defined(__APPLE__) && defined(__clang__) && defined(_LIBCPP_VERSION) might be enough here.

Technically, we have Apple clang with system runtime and LLVM clang with system runtime or its own runtime. Recent LLVM clang with its own libc++ should work, and they can be used at least back to 10.5.
Do we have a macro to differentiate between these?

[jagerman]

With f6172d5 this is now:

#if defined(__APPLE__) && defined(__clang__)

and the redundant extra __APPLE__ check was fixed in 096b289.

Do we have a macro to differentiate between these?

I don't know; the last time I looked at this there was no simple compiler predef to disambiguate, but if you know of something I'd happily put it in.