ldionne wrote:
> Have you tested this with a multi-target runtime build? My fix was slightly
> different so maybe you won't have the same problem, but I ran into an issue
> where clang would pick up the libc++ build for watchos instead of the one
> build for macOS. Here is an example of the error:
> https://github.com/llvm/llvm-project/actions/runs/18506722806/job/52742884609?pr=163026
Yes, I am doing a bootstrapping build of Clang + compiler-rt + libc++ for
multiple targets (well, it does that by default for compiler-rt AFAICT).
However, I am running into a different issue that I am still investigating: the
compiler-rt build is creating fat libraries for e.g. `x86_64`, `arm64` and
`arm64e` in a single go, i.e. within a single build of compiler-rt. However,
the libc++ build creates a library built for a single target, and instead it
gets built multiple times via `runtimes/CMakeLists.txt`. With this patch, we
(correctly) link against the just-built `<install>/usr/lib/libc++.dylib`
instead of the macOS system `<SDK>/usr/lib/libc++.dylib`. However, since that
library is NOT a fat library (unlike the compiler-rt libraries), we end up with
unresolved symbols for the architectures that aren't present in
`<install>/usr/lib/libc++.dylib` when trying to link compiler-rt. I believe
this is a pre-existing issue and it simply went unnoticed until now since we
were silently using the SDK-provided `libc++.dylib`, which is a fat library.
> Where does this resolve in Xcode? If it goes to
> `Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib` or
> `Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/lib/darwin`
> then I don't think we want to be adding this, as the libraries in there
> don't have a usable install name.
It would add `-L
<...>/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib`,
however in a default Apple setup with Xcode, there wouldn't be any
`libc++.dylib` to pick up from that location (so it would end up using the
SDK-provided `libc++.tbd`). There are a few other libraries like
`libclang.dylib` or `libIndexStore.dylib`, so it does mean that in principle if
you add `-lclang` you would find
`Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib`
after landing this patch whereas you wouldn't before this patch. I'm not sure
I understand why that would be a problem, though? This is what's done on other
platforms, for example on Linux the linker is passed `-L
/usr/lib/llvm-22/bin/../lib` and that directory contains a bunch of stuff:
```
$ ls /usr/lib/llvm-22/bin/../lib
LLVMPolly.so libLLVMARMInfo.a
libLLVMBitReader.a libLLVMDiff.a
libLLVMHipStdPar.a libLLVMM68kInfo.a
libLLVMOrcDebugging.a libLLVMSelectionDAG.a libLLVMVEInfo.a
libLLVMipo.a libclang.so
libclangHandleLLVM.a libclangTidyBugproneModule.a
libclangToolingInclusions.a libomp.so.5
LLVMgold.so libLLVMARMUtils.a
libLLVMBitWriter.a libLLVMDlltoolDriver.a
libLLVMIRPrinter.a libLLVMMC.a libLLVMOrcJIT.a
libLLVMSparcAsmParser.a libLLVMVectorize.a
libLTO.so libclangAPINotes.a
libclangIncludeCleaner.a libclangTidyCERTModule.a
libclangToolingInclusionsStdlib.a libompd.so
amdgcn-amd-amdhsa libLLVMAVRAsmParser.a
libLLVMBitstreamReader.a libLLVMExecutionEngine.a
libLLVMIRReader.a libLLVMMCA.a libLLVMOrcShared.a
libLLVMSparcCodeGen.a libLLVMWebAssemblyAsmParser.a
libLTO.so.22.0 libclangAST.a
libclangIncludeFixer.a libclangTidyConcurrencyModule.a
libclangToolingRefactoring.a libomptarget.so
libLLVMAArch64AsmParser.a libLLVMAsmParser.a
libLLVMCoroutines.a libLLVMExtensions.a
libLLVMLanaiAsmParser.a libLLVMMSP430Desc.a
libLLVMPowerPCDisassembler.a libLLVMSystemZCodeGen.a
libLLVMWindowsManifest.a libc++.a
libclangChangeNamespace.a libclangMove.a
libclangTidyLLVMModule.a libclangdRemoteIndexServiceProto.a
nvptx64-nvidia-cuda
libLLVMAArch64CodeGen.a libLLVMAsmPrinter.a libLLVMCoverage.a
libLLVMFileCheck.a libLLVMLanaiCodeGen.a
libLLVMMSP430Disassembler.a libLLVMPowerPCInfo.a libLLVMSystemZDesc.a
libLLVMX86AsmParser.a libc++.modules.json
libclangCodeGen.a libclangParse.a
libclangTidyLinuxKernelModule.a libclangdRemoteMarshalling.a
python3
libLLVMAArch64Desc.a libLLVMBOLTCore.a
libLLVMDWARFCFIChecker.a libLLVMFrontendAtomic.a
libLLVMLanaiDesc.a libLLVMMSP430Info.a
libLLVMProfileData.a libLLVMSystemZDisassembler.a libLLVMX86CodeGen.a
libc++.so libclangCrossTU.a
libclangQuery.a libclangTidyMPIModule.a
libclangdSupport.a python3.10
libLLVMAArch64Disassembler.a libLLVMBOLTPasses.a
libLLVMDWARFLinker.a libLLVMFrontendDirective.a
libLLVMLanaiDisassembler.a libLLVMMipsAsmParser.a
libLLVMRISCVAsmParser.a libLLVMSystemZInfo.a libLLVMX86Desc.a
libc++.so.1 libclangDaemon.a
libclangReorderFields.a libclangTidyMain.a libear
libLLVMAArch64Info.a libLLVMBOLTProfile.a
libLLVMDWARFLinkerClassic.a libLLVMFrontendDriver.a
libLLVMLanaiInfo.a libLLVMMipsCodeGen.a
libLLVMRISCVCodeGen.a libLLVMTableGen.a
libLLVMX86Disassembler.a libc++.so.1.0 libclangDaemonTweaks.a
libclangRewrite.a libclangTidyMiscModule.a
libfindAllSymbols.a
libLLVMAArch64Utils.a libLLVMBOLTRewrite.a
libLLVMDWARFLinkerParallel.a libLLVMFrontendHLSL.a
libLLVMLibDriver.a libLLVMMipsDesc.a libLLVMRISCVDesc.a
libLLVMTableGenBasic.a libLLVMX86Info.a
libc++abi.a libclangDependencyScanning.a
libclangRewriteFrontend.a libclangTidyModernizeModule.a
libgomp.so
libLLVMAMDGPUAsmParser.a libLLVMBOLTRuntimeLibs.a libLLVMDWP.a
libLLVMFrontendOffloading.a libLLVMLineEditor.a
libLLVMMipsDisassembler.a libLLVMRISCVDisassembler.a
libLLVMTableGenCommon.a libLLVMX86TargetMCA.a libc++abi.so
libclangDirectoryWatcher.a libclangSema.a
libclangTidyObjCModule.a libgomp.so.1
libLLVMAMDGPUCodeGen.a libLLVMBOLTTargetAArch64.a
libLLVMDebugInfoBTF.a libLLVMFrontendOpenACC.a libLLVMLinker.a
libLLVMMipsInfo.a libLLVMRISCVInfo.a
libLLVMTarget.a libLLVMXCoreCodeGen.a libc++abi.so.1
libclangDoc.a libclangSerialization.a
libclangTidyOpenMPModule.a libiomp5.so
libLLVMAMDGPUDesc.a libLLVMBOLTTargetRISCV.a
libLLVMDebugInfoCodeView.a libLLVMFrontendOpenMP.a
libLLVMLoongArchAsmParser.a libLLVMNVPTXCodeGen.a
libLLVMRISCVTargetMCA.a libLLVMTargetParser.a libLLVMXCoreDesc.a
libc++abi.so.1.0 libclangDocSupport.a
libclangStaticAnalyzerCheckers.a libclangTidyPerformanceModule.a
liblldb-22.0.0.so
libLLVMAMDGPUDisassembler.a libLLVMBOLTTargetX86.a
libLLVMDebugInfoDWARF.a libLLVMFuzzMutate.a
libLLVMLoongArchCodeGen.a libLLVMNVPTXDesc.a libLLVMRemarks.a
libLLVMTelemetry.a libLLVMXCoreDisassembler.a
libc++experimental.a libclangDriver.a
libclangStaticAnalyzerCore.a libclangTidyPlugin.a
liblldb-22.so
libLLVMAMDGPUInfo.a libLLVMBOLTUtils.a
libLLVMDebugInfoDWARFLowLevel.a libLLVMFuzzerCLI.a
libLLVMLoongArchDesc.a libLLVMNVPTXInfo.a
libLLVMRuntimeDyld.a libLLVMTextAPI.a libLLVMXCoreInfo.a
libclang-22.0.0.so libclangDynamicASTMatchers.a
libclangStaticAnalyzerFrontend.a libclangTidyPortabilityModule.a
liblldb-22.so.1
libLLVMAMDGPUTargetMCA.a libLLVMBPFAsmParser.a
libLLVMDebugInfoGSYM.a libLLVMGlobalISel.a
libLLVMLoongArchDisassembler.a libLLVMObjCARCOpts.a
libLLVMSPIRVAnalysis.a libLLVMTextAPIBinaryReader.a libLLVMXRay.a
libclang-22.so libclangEdit.a
libclangSupport.a libclangTidyReadabilityModule.a
liblldb.so
libLLVMAMDGPUUtils.a libLLVMBPFCodeGen.a
libLLVMDebugInfoLogicalView.a libLLVMHexagonAsmParser.a
libLLVMLoongArchInfo.a libLLVMObjCopy.a
libLLVMSPIRVCodeGen.a libLLVMTransformUtils.a
libLLVMXtensaAsmParser.a libclang-22.so.1 libclangExtractAPI.a
libclangTidy.a libclangTidyUtils.a
liblldb.so.1
libLLVMARMAsmParser.a libLLVMBPFDesc.a
libLLVMDebugInfoMSF.a libLLVMHexagonCodeGen.a
libLLVMM68kAsmParser.a libLLVMObject.a libLLVMSPIRVDesc.a
libLLVMVEAsmParser.a libLLVMXtensaCodeGen.a
libclang-22.so.22 libclangFormat.a
libclangTidyAbseilModule.a libclangTidyZirconModule.a
liblldbIntelFeatures.so
...
```
So if I do e.g. `echo "int main() {}" | clang++-22 -xc++ - -v -lclang`, it find
`libclang.so` just fine within its toolchain/lib directory. Why is that a
problem?
https://github.com/llvm/llvm-project/pull/170303
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
