macOS DYLD_LIBRARY_PATH Issue - Library not loaded: @rpath/libc++.1.dylib

Hey Everyone,

I am currently facing an issue with the following command:

> swift run --package-path CodeGeneration


Fetched (2.24s)
Computing version for
Computed at 1.2.3 (0.61s)
Creating working copy for
Working copy of resolved at 1.2.3
Building for debugging...
[272/272] Linking generate-swift-syntax
Build complete! (17.20s)
dyld[21618]: Library not loaded: @rpath/libc++.1.dylib <----------
  Referenced from: <F5104EA3-23D6-34EC-B647-516182F5AFE8> ../swift-project/swift-syntax/CodeGeneration/.build/arm64-apple-macosx/debug/generate-swift-syntax
  Reason: tried: '/usr/lib/swift/libc++.1.dylib' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/libc++.1.dylib' (no such file), '/Users/rajveersingh/GitHub-OpenSource/swift-project/swift-syntax/CodeGeneration/.build/arm64-apple-macosx/debug/libc++.1.dylib' (no such file), '/Applications/' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/' (no such file), '/usr/lib/swift/libc++.1.dylib' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/libc++.1.dylib' (no such file), '/Users/rajveersingh/GitHub-OpenSource/swift-project/swift-syntax/CodeGeneration/.build/arm64-apple-macosx/debug/libc++.1.dylib' (no such file), '/Applications/' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/' (no such file)
zsh: abort      swift run --package-path CodeGeneration

This issue regarding libc++ and dyld has been there for a while, not sure what caused it.

[It's also occurring in JetBrains IDEs in Debug Mode (normal mode works), but this was fixed by adding an ENVIRONMENT VARIABLE for DYLD_LIBRARY_PATH.]
(Not related to this issue, but it's exactly the same problem)

I have also tried adding a global env to zsh and bash but doesn't resolve.

This issue is caused in several places wherever dylib is used in builds of various repos. It has been blocking my workflow for a while now.

Let me know if anyone has a potential fix, or at least temporary one to get me going!
Appreciate your time!


What version of Xcode and macOS are you using?

Current Xcode Version:

Version 15.0.1 (15A507)

Current macOS Version:

macOS Sonoma Version 14.1.1

Interesting, I'm on the same versions and am not seeing that issue. I'm not immediately sure why the load path for libc++ is using @rpath for you, it's pointing directly to the OS dylib for me (which is the behavior I'd expect):

❯ otool -L .build/debug/generate-swift-syntax
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)

Have you tried deleting CodeGeneration/.build and rebuilding? Just to double check what Xcode is being in the environment, could you show the output of xcodebuild -version? Could you also show the output of env?

As a workaround, you could try running with:

swift run -Xswiftc -runtime-compatibility-version -Xswiftc none --package-path CodeGeneration

Since I believe libc++ is only needed for the back deployment libraries, and given you're only running on an up-to-date version of macOS, you can get away without them. Though we still ought to figure out what the issue is here.

I have a feeling that when I was working on an issue with LLVM, it was related to libc++ and I was initially getting settled with the codebase.

During the process, I was exploring libc++ and had tried installing a trunk-build through the llvm site. Maybe it happened at the point of time, just thought of it.

Regarding swift-syntax, I have just started exploring and wanted to contribute to the repo as well, came across this issue by @ahoppen and many similar good-first-issues.

At the moment, I have done a cd into the swift-syntax repo (this is inside swift-project which I initially setup for contributing to swift (not sure if this is the intended way or if we need to do separate clone).

I haven't tried the deletion of .build yet, let me know the right steps for above context before I try this.

Output for env:

> env

Output for xcodebuild -version:

> xcodebuild -version
Xcode 15.0.1
Build version 15A507

Also, I thought this might be worth mentioning, although it's a rust related issue:

> ./x setup
Building bootstrap
    Finished dev [unoptimized] target(s) in 0.14s
dyld[26107]: Library not loaded: @rpath/libunwind.1.dylib
  Referenced from: <E1638B0C-A3EC-382E-AD9A-5AA346E830F0> ../rust-project/rust/build/bootstrap/debug/bootstrap
  Reason: no LC_RPATH's found
Build completed unsuccessfully in 0:00:00

You can cd CodeGeneration and then rm -rf .build to remove the build directory. Regarding project layout, you can indeed do it that way, personally I maintain a separate checkout so I can work on a feature branch without affecting how swift builds (also I like remote origin being my fork rather than the upstream). That won't affect how swift-syntax builds though.

In my case this what I get:

> otool -L .build/debug/generate-swift-syntax
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)

Also, the temporary fix did work while deleting build directory and trying again with default command didn't work, let me know if you do find a concrete fix.

Meanwhile, considering the build is now successful, how do we generate Xcode project for the same (or a similar working environment) like swift, using CMake potentially?

This sounds like it's relevant, check your /usr/local/lib, do you have a libc++.dylib in there?

You should be able to open the Package.swift (in both swift-syntax and CodeGeneration) to get a workspace you can work with.

Yeah, was just about to reply, had figured it out.

Yes, it's there.

That's the issue then :) The compilation is picking up that library instead of the one provided by the OS, and presumably it has an install name that expects an rpath that isn't being provided. I would recommend removing the libraries you installed to /usr/local/lib when you installed llvm, as they're likely to cause issues similar to this one. This is also the issue you're running into with:

You probably have a /usr/local/lib/libunwind.dylib that's being picked up instead of the OS one.

Makes sense, since last month I had this in mind, I was just afraid of messing around with these core system files, especially llvm mentioning on libc++ page about not being able to boot system in some cases.

GG, now everything works as expected, including all previous errors related rust and similar ones as well!

Thanks, appreciate your time, looking forward to merging PRs towards swift-syntax too!

1 Like

Just to mention, I did rm -rf lib* in the /usr/local/lib directory.