llvm-config: error: libLLVM-7.dylib is missing #39599
Labels
bugzilla
Issues migrated from bugzilla
build-problem
llvm-tools
All llvm tools that do not have corresponding tag
Comments
5 tasks
mppf
added a commit
to chapel-lang/chapel
that referenced
this issue
Feb 22, 2022
Fix problem with static link order with static clang and llvm This resolves a problem on CentOS 7 which has an error like this: ``` : CommandLine Error: Option 'enable-vfe' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options ``` We have some evidence that this error was caused by statically linking LLVM libraries but dynamically linking clang-cpp. For one thing, on that system, changing to statically linking both solved this issue. This PR changes chpl_llvm.py to ask `llvm-config` if it has shared libraries available (with `llvm-config --shared-mode`) and if not it will use the static linking approach for both the LLVM and clang dependencies. Additionally, when using static linking for LLVM and clang, on CentOS 7, the linker was picky about the order. Since the link line should have the things depended upon later, this PR puts the `-l` flags for clang libraries before the `-l` flags for LLVM libraries. On Mac OS X with Homebrew LLVM, we were using the same (arguably incorrect) `-l` ordering but for some reason the linker there did not complain. Note that we statically link both LLVM and clang on Mac OS X (since PR #18727). This PR leaves it this way. Historically, there have been problems with upstream LLVM and Homebrew in building a dynamic library that works with `llvm-config` (in particular the versioned file, like `libLLVM-11.dylib`, is missing). See [this LLVM bug report](llvm/llvm-project#39599). I expect that we will be able to allow dynamic linking on Mac OS X once we are able to establish that the issue is resolved. We are statically linking with CHPL_LLVM=bundled and this PR does not change that. Reviewed by @Maxrimus - thanks! - [x] 'hello' builds and runs with system LLVM on Ubuntu 21 - [x] 'hello' builds and runs with system LLVM on SLES 12 - [x] 'hello' builds and runs with system LLVM on Mac OS X with Homebrew - [x] 'hello' builds and runs with bundled LLVM on Ubuntu 21 - [x] full local testing
This was referenced Aug 30, 2022
mppf
added a commit
to chapel-lang/chapel
that referenced
this issue
Aug 31, 2022
Link LLVM and clang dynamically on Mac OS X This PR adjusts the chplenv scripts so that `chpl` builds on Mac OS X with system LLVM will link LLVM and Clang dynamically. That makes Mac OS X less of an exception in this regard. We were originally statically linking on Mac OS X with system LLVM due to problems with upstream LLVM and Homebrew in building a dynamic library that works with `llvm-config` (in particular, there were errors about a versioned file, like `libLLVM-11.dylib`, missing). See [this LLVM bug report](llvm/llvm-project#39599). However this should be fixed in Homebrew llvm@12 and newer. Note that we are currently still statically linking for CHPL_LLVM=bundled. Future Work: * I observed a problem CHPL_LLVM=none and llvm@11 on Monterey, but this problem exists also on 'main', and this PR does not make it worse. Reviewed by @ronawho - thanks! ### Testing CHPL_LLVM=system `make check` with OS or Homebrew LLVM versions * note: Homebrew docs say "10.15 or higher is recommended while 10.11-10.14 are supported on a best-effort basis". So, I only tested 10.15 and newer here. #### Mac OS X 10.15 "Catalina" - [x] llvm@11 #### Mac OS X 11 "Big Sur" - [x] llvm@11 - [x] llvm@12 - [x] llvm@13 - [x] llvm (14) #### Mac OS X 12 "Monterey" - [x] llvm@11 - [x] llvm@12 - [x] llvm@13 - [x] llvm (14)
|
I just ran into this problem and did some archeology. There seem to be two things that don't play well together: (1) (2) (1) Was introduced in 5e96fe9 on 2015-09-05. (2) Was introduced in 72303a2 on 2015-09-10. Comment https://reviews.llvm.org/D13198#283815 on (2) calls out the behavior change in (1), but it does not seem like the patch was properly updated. I think the proper fix here would be to change (2), so that |
|
The issue still exists. Here's what I have on macOS: Also #55544 seems to be a duplicate of this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extended Description
LLVM was built like so:
Revision r348444
git clone --depth=1 https://github.com/llvm-mirror/llvm
cd llvm
mkdir build
cd build
cmake
-DCMAKE_BUILD_TYPE=MinSizeRel
-DCMAKE_INSTALL_PREFIX=$PWD/install
-DLLVM_INCLUDE_EXAMPLES=OFF
-DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_BUILD_LLVM_DYLIB=ON
-DLLVM_TARGETS_TO_BUILD=''
-DCMAKE_CXX_FLAGS='-march=native'
-DCMAKE_C_FLAGS='-march=native'
-DLLVM_ENABLE_PROJECTS='clang'
..
make install
This installs LLVM to $DIR/llvm/build/install.
If I then run
$DIR/llvm/build/install/llvm-config --link-sharedI get:llvm-config: error: libLLVM-7.dylib is missing.I expected it to report
$DIR/llvm/build/install/lib/libLLVM.dylib, which does exist.Judging by llvm-config, this can't work, since the code hard-codes a
-separator:https://github.com/llvm-mirror/llvm/blob/7885d2ca5ae8da146dcb51232ea8754aa07b5708/tools/llvm-config/llvm-config.cpp#L395-L396
The text was updated successfully, but these errors were encountered: