dyld not searching in /usr/local/lib (cmd line tools 2397)

Question

Created Sep ’23

Replies 16

Boosts 5

Views 5.4k

Participants 6

It seems impossible to me, but around the time I installed the latest command line tools (xcode-select version 2397) binaries what were built with linkages to @rpath/libfoo.dyld stopped being able to find their dependency. The error looks like this.

dyld[1471]: Symbol not found: _GEOSGeomGetX
  Referenced from: <16DBE67F-CB32-31EE-BCE0-BFB58EEC9740> /Users/pramsey/tmp/capi_indexed_predicate
  Expected in:     <no uuid> unknown
zsh: abort      ./capi_indexed_predicate

If I turn on DYLD_PRINT_SEARCHING, I can see the linker giving up on the rpath entry.

dyld[1501]: find path "@rpath/libgeos_c.1.dylib"
dyld[1501]:   not found: "@rpath/libgeos_c.1.dylib"

I can work around, partially, by setting DYLD_LIBRARY_FALLBACK_PATH to have /usr/local/lib in it, but that is only a partial fix, because SIP will strip that variable for any child processes, which means most of my development and database work is borked.

This seems like a very new quirk, maybe related to the XCode 15 update, at least in my personal time line, has anyone else seen it, or have any clue as to what has changed? (Worth noting, nothing changed in my code, just one day my builds wouldn't run anymore, and that day was the day after I had installed the new commandline tools).

Boost

Answer 1

andewx OP

3w

Wanted to post a possible solution as I've had a similar issue specifically with golang itself linking shared libraries.

There is the potential issue that you are running with go run main.go. Verify that directly executing the executable from your shell or OS environment doesn't solve the issues as it helped me. This looks like a interoperability issue between golang and the underlying environment

The difference between running an executable directly with ./main and using go run main.go lies in how the Go program is built and executed:

Running with ./main:

Precompiled Binary: When you run ./main, you are executing a precompiled binary. This binary has been built using go build or a similar command, which compiles the Go source code into an executable file. RPATH Handling: The RPATH (runtime library search path) is embedded in the binary during the build process. This means any dynamic library paths specified during the build are included in the binary, allowing it to locate shared libraries at runtime. Environment Independence: Since the binary is precompiled, it does not depend on the Go environment or source files being present. It can be run on any compatible system where the necessary libraries are available. Running with go run main.go: On-the-fly Compilation: go run compiles the Go source code on-the-fly and then executes it. This is convenient for quick testing and development but is not suitable for production deployment. No Embedded RPATH: Since go run compiles the code temporarily, it does not embed RPATH information in the same way a precompiled binary does. This can lead to issues if the program relies on shared libraries that are not in standard locations or specified in the environment's library path. Dependency on Go Environment: go run requires the Go environment to be set up correctly, including having the source files and any dependencies available. In your case, the issue with "no LC_RPATH found" is likely due to the fact that go run does not embed the necessary RPATH information, whereas the precompiled binary does. This is why running the executable directly solves the problem, as it can correctly locate the required shared libraries.

0