Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
Hi Maxime, Maxime Devos writes: > On 20-04-2022 12:56, Zhu Zihao wrote: >> 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. > > IIUC, this causes the static libraries to be built, right? What the DYLIB build option does is to build a single .so which contains all of the LLVM libraries instead of having a bunch of differently named .so around. It's much simpler to use, and the recommended approach for a shared library LLVM. Maxim
Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
On 20-04-2022 12:56, Zhu Zihao wrote: 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. IIUC, this causes the static libraries to be built, right? If so, they could be moved into a separate output. I would prefer to disable static libraries, those cause problems with grafts and size usage. If not possible, I would prefer them to be in a separate output, to avoid them being used by accident and to reduce the closure size of dependents of LLVM that use the shared version. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
Hello, On Mon, Aug 22, 2022 at 11:57 PM, Maxim Cournoyer wrote: > Zhu Zihao writes: > [...] > >> # Solution >> >> I suggest to replace `-DBUILD_SHARED_LIBS:BOOL=TRUE` with >> `-DLLVM_BUILD_LLVM_DYLIB:BOOL=TRUE`. > > That's something I had been meaning to do for some time, but it fell > into the cracks. I'd welcome this change; you may want to look at > 'llvm-cling', which already builds using such flag. > Just wanted to chime in that I ran across this unexpected configuration when debugging some unrelated issues (had to do with Mesa library loading, so was looking at its dependencies). I think it would be good to follow this more expected and typical configuration for building LLVM, at least as far as I understand it. John
Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
Hi, Zhu Zihao writes: > # 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. [...] > # Solution > > I suggest to replace `-DBUILD_SHARED_LIBS:BOOL=TRUE` with > `-DLLVM_BUILD_LLVM_DYLIB:BOOL=TRUE`. That's something I had been meaning to do for some time, but it fell into the cracks. I'd welcome this change; you may want to look at 'llvm-cling', which already builds using such flag. Thanks, Maxim
[RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
# 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
