beanz added a comment.
In D61804#1499275 <https://reviews.llvm.org/D61804#1499275>, @winksaville wrote:
> When you say you don't think the build system should do this, what do you
> mean?
`llvm_add_library` supports both, because there are places where we consciously
choose to build both. That's not the problem. What I don't think the build
system should do, is take an unsupported distribution format (which is
unsupported for technical reasons), and make it supported without resolving the
technical issues.
> With the change I've made when both are specified the default cmake entity,
> ${name}, is the static libraries. When neither are specified the default is
> static or shared depending on BUILD_SHARED_LIBS which is unchanged.
I missed that you were renaming the targets before calling `llvm_add_library`
so that isn't an issue, but there are still lots of issues here. Like, if you
specify your new option to generate clang static libraries but don't specify
`BUILD_SHARED_LIBS` or `LLVM_USE_LLVM_DYLIB` each of your clang libraries will
get statically linked against its own copy of LLVM, which not only makes your
libraries big, it also makes them not work. You can't link more than one copy
of LLVM into a single process memory space safely because of LLVM's use of
global data.
> The problem is that some people want to use shared libraries and some want
> static.
Why? I generally think most people don't understand the trade-offs, and I'm not
sure we should feed into that.
> I'm trying to allow both to be built and ask the Arch Linux people to
> distribute both.
Arch Linux is in an unsupported state, and your patch isn't the way forward.
Let's rewind.
Why do "some people like shared libraries"? There are usually two reasons
people cite for linking shared libraries. One is reduced binary distribution
size because you're reducing duplication of code. The other, is the ability to
update libraries without updating tools.
The later, is not an issue here. LLVM and Clang's C++ libraries don't provide
any API or ABI stability guarantees across releases, so there is no way you're
going to reasonably update LLVM or Clang libraries without rebuilding the
applications using them.
The former can be valuable, but it comes at a cost. Dynamic resolution of
symbols slows down process launch time, and dynamic resolution of C++ link-once
ODRs are exceptionally slow. If you are building a compiler, chances are you
don't want to slow down your process launch that much. But let's pretend you
don't care. Your solution still isn't the right way to do this.
Creating component shared libraries results in duplicating all the C++
link-once ODRs across each shared module. That will not only slow down your
process launch, but bloat the size of your binary distribution.
In D61804#1499276 <https://reviews.llvm.org/D61804#1499276>, @winksaville wrote:
> It looks to me that llvm, libunwind and libcxx support building both, so the
> goal isn't unprecedented,
This is very much an apple and oranges comparison. For one, LLVM does not
support generating component dylibs and shared libs. It supports generating
libLLVM, a single dylib containing all of the LLVM components rolled together.
libunwind, libcxx, libcxxabi, are runtime libraries that are designed to allow
static linkage, and they don't link LLVM.
I apologize that I missed your thread on the dev list, because that would have
been a much better place to have this conversation. Having gone back and read
it now, it sounds to me like what you really want is a clang equivalent of
libLLVM. That is a reasonable and viable thing to want. This patch
(https://reviews.llvm.org/P8147) is a first stab. I'm happy to prepare that for
landing in Clang if that meets your needs, and that is a viable way forward.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61804/new/
https://reviews.llvm.org/D61804
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
