CC @abertelrud

@aciidb0mb3r do you know if we have another bug on this?

I think that for now we should probably default to building everything so that it works if it is relocated (so no absolute paths). One tricky thing about this is how to handle the fact that usually libraries would be put somewhere other than executables.

Usually, on Darwin, you might end up with something like -rpath @loader_path/../lib in the main executable to allow finding libraries relative to a ../lib/ install location. But if we build into debug/ during iterative development that won't work, and we would either need an extra rpath (which is wasteful, and potentially a security concern), or we would need to change how we lay out the built products (which would be my vote).

In general, we need to clean up this area.

I think rpath is being added automatically on Darwin? I remember adding rpath only for linux because it wasn't a problem on Darwin. Explicitly setting rpath to look in current directory should fix this.

I agree we should change how we layout products in the build folder, it'll probably also be a step towards supporting installable packages.

I tried on Darwin and it doesn't add absolute path if passed -install_name @rpath/libname.dylib while creating the shared library.
Is that the correct fix?

@ddunbar, do you think this is still in scope for Swift 3.0? It feels late to me to be addressing this now, though it does seem like an important issue to fix.

Out of time for Swift 3.

@swift-ci create

This was done at some point.

I think this issue still exists. For example repo: https://github.com/apple/sourcekit-lsp

after build with most recent SPM, the path to libSwiftPM.dylib is hardcoded

$ otool -L .build/x86_64-apple-macosx/release/sourcekit-lsp
.build/x86_64-apple-macosx/release/sourcekit-lsp:
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
    /Users/marcinkrzyzanowski/Devel/swift-source/sourcekit-lsp/.build/x86_64-apple-macosx/release/libSwiftPM.dylib (compatibility version 0.0.0, current version 0.0.0)

isn't it the same issue?

Comment by Jeremy David Giesbrecht (JIRA)

Yes. This is still an issue in Swift 5.0.1. (But only on macOS; Linux has never been a problem.)

mkdir Demonstration
cd Demonstration
swift package init --type executable

rm -rf Package.swift
echo '// swift-tools-version:5.0
import PackageDescription
let package = Package(
    name: "Demonstration",
    dependencies: [.package(url: "https://github.com/apple/swift-package-manager", .exact("0.4.0"))],
    targets: [.target(name: "Demonstration", dependencies: ["SwiftPM"])]
)' >> Package.swift

rm -rf Sources/Demonstration/main.swift
echo 'import Workspace
print(Workspace.self)' >> Sources/Demonstration/main.swift

swift build -c release

.build/x86_64-apple-macosx/release/Demonstration
# Workspace
# (Succeeded)

mv .build/x86_64-apple-macosx/release Install
Install/Demonstration
# dyld: Library not loaded: /Users/[...]/Demonstration/.build/x86_64-apple-macosx/release/libSwiftPM.dylib
#   Referenced from: /Users/[...]/Demonstration/Install/Demonstration
#   Reason: image not found
# Abort trap: 6

Comment by Jeremy David Giesbrecht (JIRA)

It looks like fixing it would be as simple as removing the if statement here:

(It clearly is not happening by default as the comment suggests.)

Thoughts, @aciidb0mb3r?

Comment by Jeremy David Giesbrecht (JIRA)

I just submitted a PR: #2351

Comment by Jeremy David Giesbrecht (JIRA)

The PR has been merged. This is now “resolved”, “re‐resolved”, “more fully resolved”, or something to that effect.