cmake can't find libraries Reproducible: Always
Can you provide more details please? What version/commit, what cmake are you using, what clang version(s) do you have installed, etc?
I haven't tried, but I opened this bug because you reported it didn't build without a patch. Will have a look at it soon.
We're now using the build system from kdevelop and sync with them periodically. Any fix or complaint should be filled with kdevelop, but this should be working now.
Well, after pulling from the new repo everything seems to work fine, but the (final?) link step fails. I don't think that's kdevelop's fault (kdevelop5 builds against the same llvm/clang 3.7 install). See the log.
Created attachment 96999 [details] log of the failing link command
did you build kdevelop's clang plugin too ?
Yes, evidently :) I think I have an idea of the reason for the error. I tried building clazy against Ubuntu's clang 3.7, and got an error about a missing symbol, _ZTIN4llvm27CrashRecoveryContextCleanupE. That one was resolved by adding -lLLVM-3.7 to the linker arguments, manually for now. I think that means that the clazy build system doesn't detect shared LLVM builds reliably. I know that the one I use on OS X is a shared build, and apparently that applies to the Ubuntu build too. On Linux the wrapper script also failed to take a non-standard CMAKE_INSTALL_PREFIX into account, or maybe the mismatch between that install location and the clang install prefix.
I confirm: the same fix makes the build succeed on OS X. The same issue with the missing plugin path exists though, and in addition the wrapper script assumes a .so extension while the plugin is now generated with the more standard .dylib extension on OS X. I wonder: why not install that plugin into the LLVM_ROOT that was either found or specified by the user? That might resolve the plugin not found error when a full path isn't specified in the wrapper, but will also make it possible to have plugins for different LLVM versions installed in parallel (and then the wrapper could use any kind of trick to wrap the desired clang version).
@RJVB: how did you succeed in practice? I tried compiling the clazy plugin on Mac OS X after installing cmake and llvm with brew: brew install cmake brew install brew install llvm —with-clang —with-clang-extra-tools And using cmake this way: cmake -DCMAKE_INSTALL_PREFIX=/usr/local/bin -DCMAKE_BUILD_TYPE=Release -DLLVM_ROOT=/usr/local/opt/llvm But I found very similar (if not exatly the same) linking issues. Any help is appreciated. Thanks.
RJVB, can you see previous comment ? Thanks
Antonio: apologies for the delay. I never got (saw) a notification for your question. In practice I used a personal MacPorts port to build clazy: https://github.com/RJVB/macstrop/tree/master/devel/clazy The "Portfile" contains the build instructions, the "files" directory the patches I apply. As you can see, I use Apple's install_name_tool to make ClangLazy.dylib load. I haven't rebuilt this since 8 months ago (in fact I hardly use clazy in practice) so I cannot be sure the patch still applies. I hope this helps, don't hesitate to ask if you still run into problems.
Git commit 7b1aac484be5e14affe175ba8b4300a0e981b7ea by Sergio Martins. Committed on 28/10/2016 at 23:32. Pushed by smartins into branch 'master'. Fix build on macOS when using macports llvm The clazy convenience script still needs to be updated. M +8 -0 CMakeLists.txt M +19 -0 README.md http://commits.kde.org/clazy/7b1aac484be5e14affe175ba8b4300a0e981b7ea
Git commit 543437bd8bfc167574b968ba126baf8b0827e9ef by Sergio Martins. Committed on 31/10/2016 at 12:06. Pushed by smartins into branch 'master'. clazy script on macOS uses .dylib, not .so M +1 -1 clazy.cmake http://commits.kde.org/clazy/543437bd8bfc167574b968ba126baf8b0827e9ef
Git commit d06a981605de9c3c4f7ab6bf2ef4de952ee345bf by Allen Winter. Committed on 01/11/2016 at 14:04. Pushed by winterz into branch 'master'. CMakeLists.txt - remove CLAZY_MACPORTS option; use if(APPLE) instead update README for MacPorts and Homebrew M +2 -3 CMakeLists.txt M +20 -3 README.md > http://commits.kde.org/clazy/d06a981605de9c3c4f7ab6bf2ef4de952ee345bf
I confirm that I can now compile successfully on Mac using brew packages. Thanks!
Have you tested building against LLVM versions < 3.7.9 on OS X? According to my local patches those had a versioned libLLVM name (libLLVM-${LLVM_VERSION}), at least in MacPorts. Also, while everything builds correctly, I'm seeing an error when I build and run against port:clang-3.9 : : CommandLine Error: Option 'pass-remarks' registered more than once! I cannot find anything resembling that option in the clazy sources, nor on the internal commandline (see below) so maybe this is an error in LLVM/clang? ``` env CLAZY_CHECKS=level3 clazy-mp-3.9 kk.cpp -v clang version 3.9.0 (tags/RELEASE_390/final) Target: x86_64-apple-darwin13.4.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name kk.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 253.3 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/bertin/cworks/new/Qt -ferror-limit 19 -fmessage-length 132 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -load /opt/local/libexec/llvm-3.9/lib/ClangLazy.dylib -add-plugin clang-lazy -o /var/folders/j1/1439ppj08xj8h6006s6drbq00000gs/T/kk-c33ea5.o -x c++ kk.cpp : CommandLine Error: Option 'pass-remarks' registered more than once! fatal error: error in backend: inconsistency in registered CommandLine options clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.9.0 (tags/RELEASE_390/final) Target: x86_64-apple-darwin13.4.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: Error generating preprocessed source(s). ```
I can only afford to support one clang version (3.8) on macOS. Even if you provide a patch for other versions, sooner or later they will break as I don't have bandwith to maintain all the combinations of clazy/LLVM builds.
Is there anything Mac specific in support for different clang versions? I didn't mention it but the exact same "build recipe" works fine on Linux with clang 3.9 . Why would that be any different on Mac?
(In reply to RJVB from comment #18) > Is there anything Mac specific in support for different clang versions? Apparently yes, otherwise 3.9 would also work, just like it does on Linux.
Git commit 91e005f34df7db3eb537169c2df3b65dc345dd62 by Sergio Martins. Committed on 02/11/2016 at 22:33. Pushed by smartins into branch 'master'. Fix run_tests.py on macOS Needs to load a .dylib instead of .so M +2 -0 tests/run_tests.py http://commits.kde.org/clazy/91e005f34df7db3eb537169c2df3b65dc345dd62
linking to -lLLVMSupport -lcurses -lz seems to fix it for all versions (although didn't test 3.7) Linking to libLLVM isn't a good idea since we're mixing static with dynamic libs, it results in pass-remarks being registered more than once. Linking to libLLVMSupport works on mac, although it doesn't work on Linux, no idea why. And finally, FindLLVM.cmake should be changed so it executes llvm-config --system-libs too (so it adds -lcurses and -lz)
Git commit 05262016a161d3a163ab94b5358ade7a1a1b5e78 by Sergio Martins. Committed on 02/11/2016 at 23:09. Pushed by smartins into branch 'fixing_mac'. Testing a proper mac fix M +10 -6 CMakeLists.txt M +7 -0 cmake/FindLLVM.cmake http://commits.kde.org/clazy/05262016a161d3a163ab94b5358ade7a1a1b5e78
Can you test 'fixing_mac' branch ? Works for me with 3.9 + macports Should also work with 3.7
This works with 3.7, 3.8 and 3.9 from MacPorts. However, for 3.7 I had to compensate for the fact that libLLVM is called libLLVM-3.7.dylib in that version. I have no idea whether that's a MacPorts thing or not. I'll attach a patch.
but we're not linking to libLLVM.dylib, it's all static libs.. so why is that needed ? Or the static libs are also versioned ?
Created attachment 102004 [details] patch to allow building against llvm 3.7 on Mac As said, I have no idea if the versions libLLVM name is an LLVM thing or a MacPorts thing (but I don't see anything in the Portfile that suggests it is).
(In reply to Sergio Martins from comment #25) > but we're not linking to libLLVM.dylib, it's all static libs.. so why is > that needed ? Or the static libs are also versioned ? Well, no, I'm getting dynamic libs. Maybe it depends on how llvm and clang were built? In fact, it seems that linking libLLVM isn't even required, is that possible?!
the clazy branch fixing_mac doesn't even link to libLLVM
This is what I have in the llvm lib dir: > lc /opt/local/libexec/llvm-3.9/lib/libLLVM* libLLVM.dylib* libLLVMCodeGen.a libLLVMMipsAsmParser.a libLLVMSparcDisassembler.a libLLVMAArch64AsmParser.a libLLVMCore.a libLLVMMipsAsmPrinter.a libLLVMSparcInfo.a libLLVMAArch64AsmPrinter.a libLLVMCoverage.a libLLVMMipsCodeGen.a libLLVMSupport.a libLLVMAArch64CodeGen.a libLLVMDebugInfoCodeView.a libLLVMMipsDesc.a libLLVMSymbolize.a libLLVMAArch64Desc.a libLLVMDebugInfoDWARF.a libLLVMMipsDisassembler.a libLLVMSystemZAsmParser.a libLLVMAArch64Disassembler.a libLLVMDebugInfoPDB.a libLLVMMipsInfo.a libLLVMSystemZAsmPrinter.a libLLVMAArch64Info.a libLLVMExecutionEngine.a libLLVMNVPTXAsmPrinter.a libLLVMSystemZCodeGen.a libLLVMAArch64Utils.a libLLVMGlobalISel.a libLLVMNVPTXCodeGen.a libLLVMSystemZDesc.a libLLVMAMDGPUAsmParser.a libLLVMHexagonAsmParser.a libLLVMNVPTXDesc.a libLLVMSystemZDisassembler.a libLLVMAMDGPUAsmPrinter.a libLLVMHexagonCodeGen.a libLLVMNVPTXInfo.a libLLVMSystemZInfo.a libLLVMAMDGPUCodeGen.a libLLVMHexagonDesc.a libLLVMObjCARCOpts.a libLLVMTableGen.a libLLVMAMDGPUDesc.a libLLVMHexagonDisassembler.a libLLVMObject.a libLLVMTarget.a libLLVMAMDGPUDisassembler.a libLLVMHexagonInfo.a libLLVMObjectYAML.a libLLVMTransformUtils.a libLLVMAMDGPUInfo.a libLLVMIRReader.a libLLVMOption.a libLLVMVectorize.a libLLVMAMDGPUUtils.a libLLVMInstCombine.a libLLVMOrcJIT.a libLLVMX86AsmParser.a libLLVMARMAsmParser.a libLLVMInstrumentation.a libLLVMPasses.a libLLVMX86AsmPrinter.a libLLVMARMAsmPrinter.a libLLVMInterpreter.a libLLVMPowerPCAsmParser.a libLLVMX86CodeGen.a libLLVMARMCodeGen.a libLLVMLTO.a libLLVMPowerPCAsmPrinter.a libLLVMX86Desc.a libLLVMARMDesc.a libLLVMLibDriver.a libLLVMPowerPCCodeGen.a libLLVMX86Disassembler.a libLLVMARMDisassembler.a libLLVMLineEditor.a libLLVMPowerPCDesc.a libLLVMX86Info.a libLLVMARMInfo.a libLLVMLinker.a libLLVMPowerPCDisassembler.a libLLVMX86Utils.a libLLVMAnalysis.a libLLVMMC.a libLLVMPowerPCInfo.a libLLVMXCoreAsmPrinter.a libLLVMAsmParser.a libLLVMMCDisassembler.a libLLVMProfileData.a libLLVMXCoreCodeGen.a libLLVMAsmPrinter.a libLLVMMCJIT.a libLLVMRuntimeDyld.a libLLVMXCoreDesc.a libLLVMBPFAsmPrinter.a libLLVMMCParser.a libLLVMScalarOpts.a libLLVMXCoreDisassembler.a libLLVMBPFCodeGen.a libLLVMMIRParser.a libLLVMSelectionDAG.a libLLVMXCoreInfo.a libLLVMBPFDesc.a libLLVMMSP430AsmPrinter.a libLLVMSparcAsmParser.a libLLVMipo.a libLLVMBPFInfo.a libLLVMMSP430CodeGen.a libLLVMSparcAsmPrinter.a libLLVMBitReader.a libLLVMMSP430Desc.a libLLVMSparcCodeGen.a libLLVMBitWriter.a libLLVMMSP430Info.a libLLVMSparcDesc.a
(In reply to Sergio Martins from comment #28) > the clazy branch fixing_mac doesn't even link to libLLVM Oops, cross-over. Indeed, that corresponds to my observation!
Except that then you need to get rid of this: -if(APPLE) - target_link_libraries(clazylib LLVM) -endif() because that adds -lLLVM to the link command. That'll succeed except with 3.7 where that library doesn't exist.
that was an oversight, everything builds ok for you without it ? I'll remove it soon
Yep, after removing that everything builds and runs against 3.7, 3.8 and 3.9 . Note I've only tested it against a simple file that contains nothing clazy complains about even at level3 but I don't really suspect any platform-specific differences in the execution of the checks.
Git commit b0c2518868f2714910af614b0f5e73cf17a747f5 by Sergio Martins. Committed on 03/11/2016 at 18:37. Pushed by smartins into branch 'master'. Do a proper mac fix Don't mix static and dynamic libs, what we really need is to link against libLLVMSupport.a so it builds fine. This also fixes build against 3.7 and a 3.9 runtime error about something being registered more than once (because libLLVM had duplicate stuff). M +10 -10 CMakeLists.txt M +4 -3 README.md M +7 -0 cmake/FindLLVM.cmake http://commits.kde.org/clazy/b0c2518868f2714910af614b0f5e73cf17a747f5