odin @0.2024.01: Library not loaded: @rpath/libc++.1.dylib; Reason: no LC_RPATH's found

[kwolcott]

sudo port -v -s install odin

fails, here's an excerpt (might not be useful)

dyld[8393]: Library not loaded: @rpath/libc++.1.dylib
  Referenced from: <C6B9063A-B388-31E6-B9C1-7B850C31F475> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_odin/odin/work/odin-2024-01/odin
  Reason: no LC_RPATH's found
./build_odin.sh: line 122:  8393 Abort trap: 6           ./odin run examples/demo/demo.odin -file -- Hellope World
make: *** [release] Error 134
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_odin/odin/work/odin-2024-01" && /usr/bin/make -j8 release

[mohd-akram (Mohamed Akram)]

Not clear what's the cause of this, but binaries are available for macOS 14. Try installing with the -t tracing flag.

[kwolcott]

I'm using Apple Silicon, so I cannot use the "-t" flag (unless that problem has been fixed).

I want to make certain that I don't get an Intel/amd binary, so I always build from source when I install/upgrade.

Thanks, Ken Wolcott

[ryandesign (Ryan Carsten Schmidt)]

Replying to mohd-akram:

Not clear what's the cause of this, but binaries are available for macOS 14.

The macOS 14 buildbot workers use Xcode 15.2. This may be a new problem in Xcode 15.3.

Replying to kwolcott:

I'm using Apple Silicon, so I cannot use the "-t" flag (unless that problem has been fixed).

As far as I know, that problem has not been solved.

I want to make certain that I don't get an Intel/amd binary, so I always build from source when I install/upgrade.

MacPorts knows what architecture your machine is and will give you the right architecture when you install a port, regardless of whether you build from source or get a binary. (The binaries were, after all, created by MacPorts building the port from source.) "The right architecture" may be x86_64 on an Apple Silicon machine if it or its dependencies cannot be built for arm64.

[mohd-akram (Mohamed Akram)]

I tried again on my Intel machine and it builds fine using Xcode 15.3, although there's an interesting warning: ld: warning: no platform load command found in '/opt/local/var/macports/build/_Users_mohamed_.ports_lang_odin/odin/work/odin-2024-01/demo.o', assuming: macOS. The failing build might be an arm64 issue only. OP is also building on macOS 14.2.1 and using Xcode 15.2 per the log. I'd suggest updating both, maybe that will fix it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mohd-akram:

OP is also building on macOS 14.2.1 and using Xcode 15.2 per the log. I'd suggest updating both, maybe that will fix it.

While it's a fine idea to update the OS (and to a lesser extent Xcode due to all the problems we already know the 15.3 release has caused), I doubt it will help because that is what we use on our build machine; see the Information section at the bottom of ​https://build.macports.org/buildslaves/ports-14_arm64.

What seems clear from the error message is that some copy of libc++.1.dylib somewhere has the install name @rpath/libc++.1.dylib and whatever is trying to link with it has not specified (by using the right -rpath flag) what @rpath shall expand to. We cannot check what the install name of /usr/lib/libc++.1.dylib is because as of macOS 11 Apple no longer stores libraries in the filesystem, only in the dynamic library cache, however I've never known Apple to use @rpath in system libraries before. And in MacPorts we try not to use @rpath either because of the problems it causes (the error in this ticket is one such problem). Nevertheless, on my macOS 12 x86_64 machine, I see that the clang-17 port's copy of libc++.1.dylib does use @rpath:

% otool -L /opt/local/libexec/llvm-17/lib/libc++.1.dylib
/opt/local/libexec/llvm-17/lib/libc++.1.dylib:
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)

So perhaps the odin build is, for some reason, using clang-17's libc++.1.dylib instead of the system's copy. If so, the question would be why and whether we can stop that from happening. If not, then the fixes are either to fix the clang-17 port so that its libraries don't use @rpath, or to have odin and anybody else that needs to link with clang-17's libraries specify the correct -rpath flag.

[kencu (Ken)]

Does this software try to link in some LLVM libraries?

This is a common problem noted when some port tries to link in the LLVM libraries and finds a copy of libc++ in there too.

You almost never want that copy of libc++ found there.

Homebrew created a subdirectory for libc++ moved it and libc++abi, and friends, in there to prevent this from happening.

You probably should not try to change the clang ports to not use @rpaths. They need to use them or bad things happen. The clang ports were changed to use @rpaths to get past a bunch of tickets that were occurring when they did not use @rpaths.

[kencu (Ken)]

yes, it uses LLVM config to link in some LLVM libraries.

:info:build + /usr/bin/clang++ src/main.cpp src/libtommath.cpp -Wno-switch -Wno-macro-redefined -Wno-unused-value -I/opt/local/include '-DODIN_VERSION_RAW="dev-2024-01"' -Os -stdlib=libc++ -std=c++14 -I/opt/local/libexec/llvm-17/include -std=c++17 -stdlib=libc++ -fno-exceptions -funwind-tables -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -L/opt/local/libexec/llvm-17/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names -O3 -L/opt/local/lib -Wl,-headerpad_max_install_names -pthread -lm -lstdc++ -liconv -ldl -framework System -lLLVMWindowsManifest -lLLVMXRay -lLLVMLibDriver -lLLVMDlltoolDriver -lLLVMCoverage -lLLVMLineEditor -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMX86TargetMCA -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lLLVMWebAssemblyDisassembler -lLLVMWebAssemblyAsmParser -lLLVMWebAssemblyCodeGen -lLLVMWebAssemblyUtils -lLLVMWebAssemblyDesc -lLLVMWebAssemblyInfo -lLLVMVEDisassembler -lLLVMVEAsmParser -lLLVMVECodeGen -lLLVMVEDesc -lLLVMVEInfo -lLLVMSystemZDisassembler -lLLVMSystemZAsmParser -lLLVMSystemZCodeGen -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSparcDisassembler -lLLVMSparcAsmParser -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMRISCVTargetMCA -lLLVMRISCVDisassembler -lLLVMRISCVAsmParser -lLLVMRISCVCodeGen -lLLVMRISCVDesc -lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCAsmParser -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMMSP430Disassembler -lLLVMMSP430AsmParser -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMLoongArchDisassembler -lLLVMLoongArchAsmParser -lLLVMLoongArchCodeGen -lLLVMLoongArchDesc -lLLVMLoongArchInfo -lLLVMLanaiDisassembler -lLLVMLanaiCodeGen -lLLVMLanaiAsmParser -lLLVMLanaiDesc -lLLVMLanaiInfo -lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonAsmParser -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMBPFDisassembler -lLLVMBPFAsmParser -lLLVMBPFCodeGen -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMAVRDisassembler -lLLVMAVRAsmParser -lLLVMAVRCodeGen -lLLVMAVRDesc -lLLVMAVRInfo -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAMDGPUTargetMCA -lLLVMAMDGPUDisassembler -lLLVMAMDGPUAsmParser -lLLVMAMDGPUCodeGen -lLLVMAMDGPUDesc -lLLVMAMDGPUUtils -lLLVMAMDGPUInfo -lLLVMAArch64Disassembler -lLLVMAArch64AsmParser -lLLVMAArch64CodeGen -lLLVMAArch64Desc -lLLVMAArch64Utils -lLLVMAArch64Info -lLLVMOrcJIT -lLLVMWindowsDriver -lLLVMMCJIT -lLLVMJITLink -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMOrcTargetProcess -lLLVMOrcShared -lLLVMDWP -lLLVMDebugInfoLogicalView -lLLVMDebugInfoGSYM -lLLVMOption -lLLVMObjectYAML -lLLVMObjCopy -lLLVMMCA -lLLVMMCDisassembler -lLLVMLTO -lLLVMCFGuard -lLLVMFrontendOpenACC -lLLVMFrontendHLSL -lLLVMExtensions -lPolly -lPollyISL -lLLVMPasses -lLLVMCoroutines -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMFrontendOpenMP -lLLVMDWARFLinkerParallel -lLLVMDWARFLinker -lLLVMGlobalISel -lLLVMMIRParser -lLLVMAsmPrinter -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMTarget -lLLVMObjCARCOpts -lLLVMCodeGenTypes -lLLVMIRPrinter -lLLVMInterfaceStub -lLLVMFileCheck -lLLVMFuzzMutate -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMSymbolize -lLLVMDebugInfoBTF -lLLVMDebugInfoPDB -lLLVMDebugInfoMSF -lLLVMDebugInfoDWARF -lLLVMObject -lLLVMTextAPI -lLLVMMCParser -lLLVMIRReader -lLLVMAsmParser -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMBitReader -lLLVMFuzzerCLI -lLLVMCore -lLLVMRemarks -lLLVMBitstreamReader -lLLVMBinaryFormat -lLLVMTargetParser -lLLVMTableGen -lLLVMSupport -lLLVMDemangle -lm -lz -lzstd -lcurses -lxml2 -o odin

so this is exactly the situation that homebrew ran into.

The only good solution is to move libcxx to another place, like a subdir of /opt/local/libexec/llvm-17/lib

[mohd-akram (Mohamed Akram)]

As a first step, libc++ and libc++abi should be packaged as separate ports, eg. libc++-17 and libc++abi-17. They're technically not part of Clang and this is how they are packaged on other platforms.

[kencu (Ken)]

First step or second step, either way, libc++ and friends should not be in the same folder as the rest of the LLVM and clang libraries to be found opportunistically when trying to link in LLVM or clang libraries, whether they are left as part of the clang installation or spun off into some separate port.

[kencu (Ken)]

libc++ being installed with the clang port was done because the clang ports require the entire current c++ headers installed by the libcxx subproject, and installing all that is a one-liner in the configuration. So installing the headers that way was much easier than the previous option.

I considered whether to delete the libc++ libraries from the installation -- but I left them as they were going to be useful for the macports-libcxx port anyway, and I thought they might be useful to have to experiment with.

In retrospect, I would have moved them to subdirectory in the first place so they would not be opportunistically found. At the time I set this up all those years ago, it was not so clear to me that the libc++ libraries were going to be opportunistically found. It is clear now.

If the libcxx subproject becomes yet another subport of llvm, all that means is another entire build process of clang to get the libcxx parts installed too. It could be done. It seems kinda pointless to force another whole build process just for that -- just move the libc++ libraries into the subfolder post-destroot, and we're done.

[mohd-akram (Mohamed Akram)]

Is there no way to prevent the compiler/linker from picking up libc++.dylib despite it being in the path?

If the libcxx subproject becomes yet another subport of llvm, all that means is another entire build process of clang to get the libcxx parts installed too.

I think it will just build libcxx, no?

First step or second step, either way, libc++ and friends should not be in the same folder as the rest of the LLVM and clang libraries

True, hopefully this can be fixed soon because this is also causing issues with the zig port.