-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[libc][libcxx] Support for building libc++ against LLVM libc #99287
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
7d7a788
[libc][libcxx] Support for building libc++ against LLVM libc
petrhosek 76e5e02
Introduce the LIBCXX_LIBC option
petrhosek c6ca8cf
Review feedback
petrhosek 1418ea8
Review feedback
petrhosek a27eaa4
Remove unnecessary changes
petrhosek 1777997
Change dependency visibility
petrhosek 9f90269
Update formatting
petrhosek 0cafc79
Merge remote-tracking branch 'origin/main' into libcxx-use-libc
petrhosek File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to avoid introducing a CMake setting like this. Instead, we should do something similar to the way we handle ABI choices and provide a pseudo-target that represents the libc we're building against. We can then have a multi-valued option like
LIBCXX_LIBC="llvm-libc|system-libc|musl|etc..."
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was my original thought, but I don't think the different C libraries have enough granularity for this to be anything but a binary flag in practice. What this flag truly means is whether or not to use the LLVM
libc
built in-tree or not. It's basically the exact same use-case as the already presentLIBCXXABI_USE_LLVM_UNWINDER
. If someone installed the LLVM libc globally, then the existing logic would just pick it up as thelibc
without this flag.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The benefit of that approach is that we can define how to build against arbitrary new C stdlibs very easily, and we avoid adding more logic than there already is in the
CMakeLists.txt
. I don't mind if we start with only two configurations for this flag, what matters to me is that we use the right approach to introduce this new functionality.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I don't think that config easily exposes what we're trying to express, since you could say
llvm-libc
and it wouldn't disambiguate betweenllvm-libc
installed on the system globally andllvm-libc
that exists as a target inside the current CMake project. So, we'd still need a flag in that case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a solution to the same problem for selecting the ABI library:
set(LIBCXX_SUPPORTED_ABI_LIBRARIES none libcxxabi system-libcxxabi libcxxrt libstdc++ libsupc++ vcruntime)
.There's
libcxxabi
(in-tree) andsystem-libcxxabi
(whatever libc++abi is installed on the system).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then we should have
system system-llvm-libc llvm-libc
, wheresystem
is the current default (Just use whatever you find in the default include path).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how
system-llvm-libc
would differ fromsystem
, but yeah that sounds about right.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary for now, was just thinking how if we started adding new ones like
musl
orglibc
then we'd need to disambiguate. Right now we probably just wantsystem
as the default andllvm-libc
which mirrors this patch's binary selection well enough.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I introduced
LIBCXX_LIBC
which currently acceptssystem
orllvm-libc
.system
is currently no-op but that can be expanded later. In the future we may also want to introduce additional options e.g.musl
replacing the existingLIBCXX_HAS_MUSL_LIBC
option but I'd prefer to do it in a separate change.I'm not sure if it's better to set the
-nostdlibinc
and-nolibc
on the libc side (as interface flags on the targets) or on the libc++ side (as interface flags on the proxy targets), I can see an argument for doing either way. Right now I set those on the libc side which has the upside of not needing to duplicate those flags in libunwind and libc++abi which should eventually support LLVM libc as well.In the future we'll probably want to move
HandleLibC.cmake
to the top-levelcmake/Modules
directory so they can be shared by libc++abi and libunwind, although we'll need to rethink the target and variables names because theLIBCXX_
andlibcxx-
prefix is undesirable (maybe we can useRUNTIMES_
andruntimes-
)?