# Editing rpaths for \_InternalSwiftSyntaxParser

DevFeed: [Editing rpaths for \_InternalSwiftSyntaxParser](<https://devfeed.tech/articles/editing-rpaths-for-internalswiftsyntaxparser-25401.md>)

Original publisher: [Read original article](<https://smileykeith.com/2021/03/03/editing-rpaths/>)

Author: Keith Smiley

Published: 2021-03-04T03:48:00Z

Content type: tutorial

Language: en

Sources: [Keith Smiley](<https://devfeed.tech/sources/keith-smiley.md>)

Topics: [Swift](<https://devfeed.tech/topics/swift.md>), [Xcode](<https://devfeed.tech/topics/xcode.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [swift](<https://devfeed.tech/tags/swift.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [xcode](<https://devfeed.tech/tags/xcode.md>)

## AI overview

This tutorial explains how to edit runtime search paths (rpaths) so a Swift command-line tool can ship and load the compatible _InternalSwiftSyntaxParser dynamic library from Xcode. It covers inspecting dependencies and rpaths with otool, copying the library, and modifying the binary's rpath entries.

## Source excerpt

One of the issues with shipping a tool that depends on SwiftSyntax is that it depends on a dynamic library that is provided with Xcode called _InternalSwiftSyntaxParser. This library provides some of Swift's logic for how to parse Swift code. When you run a command line tool that was built with a different version of Xcode than what you have installed locally, you hit this issue: <unknown>:0:0: error: The loaded '_InternalSwiftSyntaxParser' library is from a toolchain that is not compatible with this version of SwiftSyntax Ideally, this library would be statically linked to your executable (and I'm hoping we can find a solution to this) so you would no longer have to worry about this. In the meantime, we can work around this issue by shipping the version of the library from Xcode alongside your executable, and loading that instead. This will increase your distribution archive's size, but make it easier to support multiple versions of Xcode at once. The key to this workaround relies on how dyld works. dyld is responsible for loading the dynamic libraries your binary depends on. First, it's useful for you to see what libraries you depend on with otool. For example: % otool -L ./.build/debug/drstring-cli ./.build/debug/drstring-cli: ... /usr/lib/swift/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 1.0.0, weak) /usr/lib/swift/libswiftXPC.dylib (compatibility version 1.0.0, current version 1.1.0, weak) @rpath/lib_InternalSwiftSyntaxParser.dylib (compatibility version 1.0.0, current version 17013.0.0) Here you can see many libraries are directly referenced with their absolute paths while lib_InternalSwiftSyntaxParser.dylib, the library we're specifically interested in, is referenced via a rpath. You can run this command to see your binary's rpaths (yours may differ depending on your absolute path to Xcode): % otool -l ./.build/debug/drstring-cli \ | grep -A2 LC_RPATH \ | grep "^\s*path" | cut -d " " -f 11 @loader_path /Applications/Xcode-12.4.0.app