-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggested fixes for variant.h
#24
Comments
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++). |
In theory, |
@jagerman GCC normally (by default) uses For clang, it may work with |
Technically, we have Apple clang with system runtime and LLVM clang with system runtime or its own runtime. Recent LLVM clang with its own |
With f6172d5 this is now:
and the redundant extra
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. |
@jagerman Returning to this finally.
oxen-encoding/oxenc/variant.h
Lines 16 to 21 in d6f300d
Should be just:
This is non-functional, but the code will be neater.
variant.h
does not seem to encounter any issues when GCC is used: variant.h: minor fixes for Darwin #16 (comment)I have also verified that with
oxen-encoding
1.0.8 now.Should I test something else, or we can make a “broken” fallback conditional on Clang?
The text was updated successfully, but these errors were encountered: