-
Notifications
You must be signed in to change notification settings - Fork 66
Importing third-party packages before TensorFlow causes a runtime error #4
Comments
Thanks for providing so much detail! |
I was able to replicate the issue:
The solution is to add an extra
I tested the Swift interpreter by putting the code into This worked without specifying On Linux, the Swift shared runtime library path is found at In lib/Driver/Toolchains.cpp (used by the interpreter/compiler), The REPL uses entirely separate logic for linking libraries (somewhere in google/swift-lldb). I'll do some digging and try to fix this. This linking is probably related to #5. |
@dan-zheng - nice work man. This is exactly what I was missing. See the following:
** edited formatting |
I'm working on a simple fix now. |
I believe this is fixed in 1969380. |
…ries on Linux. Addresses google#4. On Linux, the REPL fails with "Couldn't lookup symbols" errors when: - Linking an external Swift shared library (produced by `swift build`) and importing the corresponding Swift module. - Importing the `TensorFlow` and `Python` modules, without manually linking `libswiftPython.so` and `libswiftTensorFlow.so`. A manual workaround involves specifying the `-lswiftPython` and `-lswiftTensorFlow` flags (in that specific order) when invoking the REPL. Also, `Python` and `TensorFlow` must be imported before the external Swift module to avoid the error. Conditionally adding the linker flags here seems to solve the issue. This is robust assuming that toolchain artifacts are not manipulated (so that somehow `Python.swiftmodule` exists while `libswiftPython.so` doesn't). PiperOrigin-RevId: 195572160
…ries on Linux. Addresses google#4. On Linux, the REPL fails with "Couldn't lookup symbols" errors when: - Linking an external Swift shared library (produced by `swift build`) and importing the corresponding Swift module. - Importing the `TensorFlow` and `Python` modules, without manually linking `libswiftPython.so` and `libswiftTensorFlow.so`. A manual workaround involves specifying the `-lswiftPython` and `-lswiftTensorFlow` flags (in that specific order) when invoking the REPL. Also, `Python` and `TensorFlow` must be imported before the external Swift module to avoid the error. Conditionally adding the linker flags here seems to solve the issue. This is robust assuming that toolchain artifacts are not manipulated (so that somehow `Python.swiftmodule` exists while `libswiftPython.so` doesn't). PiperOrigin-RevId: 195572160
…ries on Linux. Addresses google#4. On Linux, the REPL fails with "Couldn't lookup symbols" errors when: - Linking an external Swift shared library (produced by `swift build`) and importing the corresponding Swift module. - Importing the `TensorFlow` and `Python` modules, without manually linking `libswiftPython.so` and `libswiftTensorFlow.so`. A manual workaround involves specifying the `-lswiftPython` and `-lswiftTensorFlow` flags (in that specific order) when invoking the REPL. Also, `Python` and `TensorFlow` must be imported before the external Swift module to avoid the error. Conditionally adding the linker flags here seems to solve the issue. This is robust assuming that toolchain artifacts are not manipulated (so that somehow `Python.swiftmodule` exists while `libswiftPython.so` doesn't). PiperOrigin-RevId: 195572160
This should be able to be solved by -module-link-name . That avoids this hack into the compiler. |
I've reproduced linking this way outside of the swift compiler. This is also the way that foundation and xctest works. That avoids the problem of linking these libs into every binary if they are needed or not. |
Continuing our discussion from the group here.
Full background - I've just copied my comment directly from the group:
I've had some success in using third-party SPM packages by creating a dynamic library and linking to it when launching the REPL, however, it seems like the import order of TensorFlow vs other packages is important; importing the 3rd-party lib first causes a C++ runtime error in TensorFlow.
Here's some snippets:
Package.swift
... then we just fetch dependencies and build with vanilla commands, then invoke the REPL:
Invocation
swift -I/usr/lib/swift/clang/include -I/usr/src/TFExample/.build/debug -L/usr/src/TFExample/.build/debug -lTFExample
At this point, I'm able to import RxSwift and TensorFlow in the REPL without errors in any order; however, when I actually interact with the packages, the incorrect import order does result in a runtime error:
Scenario 1 (OK)
Scenario 2 (runtime error)
The full process is outlined here if more detail is necessary: https://github.com/zachgrayio/swift-tensorflow/blob/example/package/README.md#run-with-dependencies-advanced
The text was updated successfully, but these errors were encountered: