@@ -267,36 +267,6 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
267
267
} else {
268
268
Arguments.push_back (context.Args .MakeArgString (SharedRuntimeLibPath));
269
269
Arguments.push_back (" -lswiftCore" );
270
-
271
- // SWIFT_ENABLE_TENSORFLOW
272
- // On Linux, the REPL fails with "Couldn't lookup symbols" errors when:
273
- // - Linking an external Swift shared library (produced by `swift build`)
274
- // and importing the corresponding Swift module.
275
- // - Importing the `TensorFlow` and `Python` modules, without manually
276
- // linking `libswiftPython.so` and `libswiftTensorFlow.so`.
277
- //
278
- // A manual workaround involves specifying the `-lswiftPython` and
279
- // `-lswiftTensorFlow` flags (in that specific order) when invoking the
280
- // REPL. Also, `Python` and `TensorFlow` must be imported before the
281
- // external Swift module to avoid the error.
282
- //
283
- // Conditionally adding the linker flags here seems to solve the issue.
284
- // This is robust assuming that toolchain artifacts are not manipulated
285
- // (so that somehow Python.swiftmodule exists while libswiftPython.so
286
- // doesn't).
287
- //
288
- // https://github.com/google/swift/issues/4
289
- SmallString<128 > swiftPythonLibPath = SharedRuntimeLibPath;
290
- llvm::sys::path::append (swiftPythonLibPath, " libswiftPython.so" );
291
- if (llvm::sys::fs::exists (swiftPythonLibPath))
292
- Arguments.push_back (" -lswiftPython" );
293
-
294
- SmallString<128 > swiftTensorFlowLibPath = SharedRuntimeLibPath;
295
- llvm::sys::path::append (swiftTensorFlowLibPath, " libswiftTensorFlow.so" );
296
- if (llvm::sys::fs::exists (swiftTensorFlowLibPath)) {
297
- Arguments.push_back (" -lswiftTensorFlow" );
298
- Arguments.push_back (" -ltensorflow" );
299
- }
300
270
}
301
271
302
272
// Explicitly pass the target to the linker
0 commit comments