From: Zhu Zihao <all_but_last@163.com>
To: Guix Devel <guix-devel@gnu.org>
Subject: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
Date: Wed, 20 Apr 2022 18:56:15 +0800 [thread overview]
Message-ID: <867d33tpui.fsf@163.com> (raw)
# Background
Now in Guix. LLVM is built with configure flag
"-DBUILD_SHARED_LIBS:BOOL=TRUE". According to
https://llvm.org/docs/CMake.html. Build LLVM with `BUILD_SHARED_LIBS` is
not recommended for non LLVM developing usage. LLVM says that packager
should use `LLVM_BUILD_LLVM_DYLIB` instead.
The main difference between `LLVM_BUILD_LLVM_DYLIB` and
`BUILD_SHARED_LIBS` is the former one will generate a monolith shared
library called `libLLVM.so` and the latter will generate individual
libLLVMCore.so libLLVMXXX.so ...
# Issue
`BUILD_SHARED_LIBS` works for us now. But this configure flags will
violates some setup of the cmake script of LLVM.
LLVM components provides an cmake option called `LLVM_LINK_LLVM_DYLIB`
to let user to choose whether dynamically linked or not. Our build
breaks this option.
In lib/cmake/llvm/AddOCaml.cmake:69
```
if(LLVM_LINK_LLVM_DYLIB)
list(APPEND ocaml_flags "-lLLVM")
else()
```
If the add_ocaml_library function is used and `LLVM_LINK_LLVM_DYLIB` is
set to true, it'll tries to link the libLLVM.so which is not provided by
us.
This issue also exists for add_llvm_library.
Though this looks like the issue of LLVM, because `llvm-config`
executable works well for us: if you pass `--link-static` to
llvm-config, it will complain that static archive files is not found.
And if pass `--link-shared`, it can generate the command args that link
to individual shared library.
# Solution
I suggest to replace `-DBUILD_SHARED_LIBS:BOOL=TRUE` with
`-DLLVM_BUILD_LLVM_DYLIB:BOOL=TRUE`.
# Cons
We may introduce following problems if we apply this solution.
1. Increase the closure size of LLVM.
By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to
build the static archive. This may increase the closure size of LLVM.
And some package linking with LLVM may use the static archive instead of
linking to the dynamic library.
My opinion: If we're OK with the bigger closure size, that's not a
problem. If not, we may consider disable the static archive generation.
For LLVM components, we can use `LLVM_LINK_LLVM_DYLIB` to ask these
packages to link with the shared version. For package use `llvm-config`
directly or indirectly, we can pass `--link-shared` to it.
--
Retrieve my PGP public key:
gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F
Zihao
next reply other threads:[~2022-08-20 6:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 10:56 Zhu Zihao [this message]
2022-08-23 3:57 ` [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS Maxim Cournoyer
2022-08-26 17:40 ` John Kehayias
2022-08-26 18:24 ` Maxime Devos
2022-09-13 2:57 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867d33tpui.fsf@163.com \
--to=all_but_last@163.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).