phosek added inline comments.
================
Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:124
set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
- set(RUNTIMES_${target}_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
----------------
ldionne wrote:
> phosek wrote:
> > ldionne wrote:
> > > Note that I am removing these options here because I don't think they are
> > > required -- since we specify `LIBCXXABI_ENABLE_SHARED=OFF`, there is no
> > > shared libc++abi to link against, so we should already be linking against
> > > `libc++abi.a` regardless of this change.
> > This option was set to merge `libc++abi.a` into `libc++.a` so to achieve
> > the same effect, presumably we would need to set
> > `-DLIBCXX_CXX_ABI=libcxxabi-objects`?
> I agree this is suspicious, but why is there no
> `LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY` specified here then? I can add
> `-DLIBCXX_CXX_ABI=libcxxabi-objects`, I just want to make sure we both
> understand what's going on.
This is intentional. We are merging `libc++abi.a` into `libc++.a` but we ship
`libc++abi.so` and `libc++.so` as separate (and use the generated linker script
to pull in `libc++abi.so` when you pass `-lc++` to linker). I'd be fine merging
`libc++abi.so` into `libc++.so` as well, but we'll need to figure out a
transition plan since there are several places in our build right now that
expect `libc++abi.so` to exist. We cannot land this change as is because that
would break the `-static-libstdc++` use case, since Clang driver only passes
`-lc++` to the linker and not `-lc++abi` and there's nothing that would pull
`libc++abi.a` in.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125683/new/
https://reviews.llvm.org/D125683
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
