0.9.2 --- a standard header compiles for every target, not only Linux - #17
Merged
Merged
Conversation
libc++'s musl locale support calls strtof_l, strtod_l, strtold_l and vasprintf, which musl declares only under _GNU_SOURCE. Clang predefines _GNU_SOURCE for C++ on Linux targets only, so any consumer translation unit that includes a standard header (every module wrapper of a header library does) failed for macOS and Windows. __config_site now states _GNU_SOURCE, and CI cross-builds examples/cxx, which includes <filesystem>, for both targets.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A consumer translation unit that includes a standard header did not compile for
the macOS or Windows target:
This configuration's locale support calls
strtof_l,strtod_l,strtold_land
vasprintf; musl declares them only under_GNU_SOURCE; and Clangpredefines
_GNU_SOURCEfor C++ on Linux targets and on no other.import stdnever showed it, because the std module is compiled with this package's own
flags. Every module wrapper of a header library does show it, because the
wrapper includes the library's headers in its own translation unit. Found
building
nlohmann.jsonfrom mcpp-index over this runtime forx86_64-windows-gnuandaarch64-macos.llvm-generated/generic/__config_sitestates_GNU_SOURCE. It is included by<__config>before any C header, including libc++'s wrappers of the C headers.examples/cxx(which includes<filesystem>) for bothtargets beside
same-source. Measured locally: without the change both buildsfail with the errors above; with it both succeed, and the Linux run of the
example still reports
failures: 0.