vgorloff/swift-everywhere-toolchain

rpath ?

Closed this issue · 11 comments

johnburkey commented

dyld: Library not loaded: @rpath/libCommands.dylib
Referenced from: /Users/johnburkey/brightenTools/swift-android-toolchain/usr/bin/swift-build
Reason: image not found

johnburkey commented
vgorloff commented

Ok. Here is how LC_RPATH looks for swift-build which comes with Xcode.

$ otool -l /Volumes/Apps/Developer/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-build | grep RPATH -A2
          cmd LC_RPATH
      cmdsize 64
         path @executable_path/../../../../../SharedFrameworks (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path @executable_path/../lib/swift/pm/llbuild (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../ (offset 12)

An here is how it looks in Android toolchain:

$ otool -l /Volumes/Shared/Git/MyProjects/swift-everywhere-toolchain/ToolChain/swift-android-toolchain/usr/bin/swift-build | grep RPATH -A2
          cmd LC_RPATH
      cmdsize 112
         path /Volumes/Shared/Git/MyProjects/swift-everywhere-toolchain/ToolChain/Build/darwin-host/spm/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 112
         path /Volumes/Shared/Git/MyProjects/swift-everywhere-toolchain/ToolChain/Build/darwin-host/llbuild/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 128
         path /Volumes/Shared/Git/MyProjects/swift-everywhere-toolchain/ToolChain/Build/darwin-host/swift-tools-support-core/lib (offset 12)

Absolute paths are used :0

johnburkey commented
johnburkey commented
vgorloff commented

Looks like missed header search path.
Ok. I will try to build some Swift package with C++ sources.

johnburkey commented
johnburkey commented

Nice work dude! I'll retest and remove our workaround. Also I found a particular version of the bug where I had to introduce a separate c++ header path before some others, and also ran into the new clang "feature" where you can't have a struct with the same name in 2 files even with the same protecting ifdef. I worked around that one by editing my android NDK header. :-(. Not your bug, but perhaps theres a way to turn off the new "feature" for these builds . Will report back with testing!

vgorloff commented

Should be fixed in https://github.com/vgorloff/swift-everywhere-toolchain/releases/tag/1.0.60.
Toolchain was built on macOS 11. May not work on Catalina :)

The order of headers sometimes plays role. One example from CoreFoundation.h.

diff --git a/CoreFoundation/Base.subproj/SwiftRuntime/CoreFoundation.h b/CoreFoundation/Base.subproj/SwiftRuntime/CoreFoundation.h
index a3ebe169bb3eacd598ab804d921c2dc9389d3f60..4ceba2c11b504c20a8dc8144f46824066ae4e265 100644
--- a/CoreFoundation/Base.subproj/SwiftRuntime/CoreFoundation.h
+++ b/CoreFoundation/Base.subproj/SwiftRuntime/CoreFoundation.h
@@ -32,12 +32,12 @@
 #include <locale.h>
 #include <math.h>
 #include <setjmp.h>
+#include <time.h>
 #include <signal.h>
 #include <stddef.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <time.h>
 
 #if __has_include(<netdb.h>)
 #include <netdb.h> // for Host.swift