macOS Big Sur beta - dyld: Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib

[klartext79]

In a clean macOS Big Sur beta 5 (20A5364e) installation with also clean Xcode 12 beta installation in an objective-c project, bartycrouch (4.2.0) can neither be loaded correctly by cocoa pods nor after installing via homebrew.

In both cases we receive

dyld: Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib Referenced from: /usr/local/bin/bartycrouch Reason: image not found zsh: abort bartycrouch

The exact same setup on a clear macOS 10.15 Catalina (newest) works.

You had an old issue named the same - but the solution can be excluded as both newest version of bartycrouch and Xcode are used.

New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

Not quite sure if this might be a thing to check or if its a beta related issue, wanted to let you know.
Might be worth having a look.

Steps to Reproduce the Problem

1. Install clean macOS Big Sur latest beta
2. Install latest Xcode 12 beta
3. Install latest Xcode Command line tools
4. Open a new project, init cocoa pods with bartycrouch pod or install via home-brew, try to compile or call bartycrouch directly on command line

[lechuckcaptain]

I had the same issue, found this workaround on another project and solved the problem:

I discovered a similar issue in a library I'm writing. A workaround was to rename Xcode-xyz.app to Xcode.app. It seems there's something in SwiftSyntax that assumes that swift toolchain will be under /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift.

realm/SwiftLint#3105 (comment)

[Jeehut]

This should be fixed with 4.3.0. Please report otherwise if it still happens.

[klartext79]

Meanwhile @lechuckcaptain 's solution worked 👍
I will test it. Thank you.

[sixten]

Just ran into this issue with version 4.6.0, Xcode 12.5.1, and macOS 11.4. I tend to have a bunch of Xcode versions installed, all with non-standard names. Creating a symbolic link at /Applications/Xcode.app, as suggested above, seems to work around the problem.