Port tests from apple/swift

[eaplatanios]

@rxwei This is part of the move to swift-apis discussed in #109.

swift build works fine, but swift test gives the following error on my machine:

[1/1] Linking DeepLearningPackageTests
2019-05-28 11:23:47.051 xctest[14729:19108935] The bundle “DeepLearningPackageTests.xctest” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
2019-05-28 11:23:47.051 xctest[14729:19108935] (dlopen_preflight(/Users/eaplatanios/Development/GitHub/swift-apis-temp/.build/x86_64-apple-macosx/debug/DeepLearningPackageTests.xctest/Contents/MacOS/DeepLearningPackageTests): Library not loaded: /usr/lib/swift/libswiftTensorFlow.dylib
  Referenced from: /Users/eaplatanios/Development/GitHub/swift-apis-temp/.build/x86_64-apple-macosx/debug/DeepLearningPackageTests.xctest/Contents/MacOS/DeepLearningPackageTests
  Reason: image not found)

Adding -Xlinker -ltensorflow does not resolve this.

[rxwei]

I think this is because of Xcode 10.2+. The Swift runtime linker search path got changed from the toolchain directory to /usr/lib/swift since Swift got ABI stability. I'm not sure how to fix this. Digging through cmake files might help, and asking a question on Swift forums would definitely help.

[eaplatanios]

That's weird because I'm not using Xcode at all for this. I'm. using swiftenv though and I'm not sure how that might affect this. I'll look into this tonight. In the meantime, could you try and run the CI tests and see if those pass?

[rxwei]

This happens even when Xcode is not being used directly. I haven't looked into the problem yet. A workaround is to xcode-select to Xcode 10.1 before running swift test.

[eaplatanios]

It seems that at some point some process copies libraries over to /usr/lib/swift, but libswiftTensorFlow.dylib and libswiftPython.dylib are not copied. Do you know when the copy is performed and by whom? This may help me figure out how to include the missing binaries. In the meantime, I will try using xcode-select as you suggested.

[eaplatanios]

Using xcode-select -switch ~/Downloads/Xcode.app/Contents/Developer were ~/Downloads/Xcode.app has version 10.1 did not resolve this. I could manually copy the missing libraries to /usr/lib/swift as a temporary solution, but I would still not know if the existing ones there are updated. To do this properly, I'd need to understand who creates this directory and copies the libraries.

[rxwei]

I see. I'm not sure copying TensorFlow libraries is ideal because /usr/lib/swift/ is supposed to contain the system Swift runtime, not ones that come from custom toolchains.

You could also try setting the linker path manually.

swift test -Xlinker -ltensorflow -Xlinker -L<path to usr/lib in your S4TF toolchain>

[eaplatanios]

I tried that, but it also doesn't work. I think it's because the path /usr/lib/swift/libswiftTensorFlow.dylib is hardcoded. The exact command I tried was:

swift test -Xlinker -ltensorflow -Xlinker -lswiftTensorFlow -Xlinker -L/Library/Developer/Toolchains/swift-tensorflow-LOCAL-2019-05-27-a.xctoolchain/usr/lib/swift/macosx

and I have verified that this directory contains the missing libraries.

[rxwei]

Hmm I'm not sure at this point. libtensorflow.so and libtensorflow_framework.so shouldn't be treated as an ABI stable system library and thus the compile shouldn't be hard-coded to link against things in /usr/lib. @bgogul Are you able to look into this?

I'll trigger CI tests now since CI runs on Linux without the linking problem.

[eaplatanios]

Sounds good. Note that this error is not about libtensorflow.so and libtensorflow_framework.so, but rather about libswiftTensorFlow.dylib and libswiftPython.dylib.

[bgogul]

It seems that at some point some process copies libraries over to /usr/lib/swift, but libswiftTensorFlow.dylib and libswiftPython.dylib are not copied. Do you know when the copy is performed and by whom?

@eaplatanios, I believe they are done at these places: build-script-impl:2580 and build-script-impl:3973.

IIRC, you made some changes to that part of the code as well.

[eaplatanios]

@eaplatanios, I believe they are done at these places: build-script-impl:2580 and build-script-impl:3973.

IIRC, you made some changes to that part of the code as well.

This only copies libtensorflow.so and libtensorflow_framework.so to the lib directory of that toolchain, which works fine. The issue is with copying (or symlinking) libswiftTensorFlow.dylib and libswiftPython.dylib in /usr/lib/swift, but I'm not sure where that happens.

Another solution would be to link to them differently. My impression is that all stdlib shared libraries get their rpath set to /usr/lib/swift somewhere, which messes up with the S4TF libraries that are not being copied there.

[eaplatanios]

I don't really understand why this is failing. It seems to not be compiling at all some of the files under the Layers subdirectory.

[eaplatanios]

@rxwei This does not depend on the latest changes to apple/swift so I tried testing locally with a previously built toolchain and all tests pass. I don't know what causes the failure on the CI although it seems to be completely ignoring some of the source files in the Layers subdirectory.

[rxwei]

Testing it locally.

[rxwei]

I have the same problem locally. Looks like layers are not being compiled.

[eaplatanios]

It's weird that this only happens for Linux and not MacOS.

[rxwei]

It's happening on macOS when I test it locally.

[eaplatanios]

I'm using a toolchain built from swiftlang/swift#24452 (my last built toolchain), but this should not cause issues. Why do you think this happens?

[rxwei]

I figured why. This was because #102 checked in some files that end with .Swift instead of .swift. Fixing them now.

[eaplatanios]

I figured why. This was because #102 checked in some files that end with .Swift instead of .swift. Fixing them now.

Oh good catch! Thanks.

[Shashi456]

@rxwei I'm extremely sorry. I thought I had rectified all those errors.

[rxwei]

@rxwei I'm extremely sorry. I thought I had rectified all those errors.

No worries at all!

[eaplatanios]

No worries @Shashi456. @rxwei I can rename the files as part of this PR and rerun the tests if this helps.

[rxwei]

I'm checking in a commit in a minute to fix this.

[rxwei]

Done in be05f0b.

[eaplatanios]

Merged. Running tests now. :)

[rxwei]

Sigh, the APFS file system is still case-insensitive by default...

[eaplatanios]

Sigh, the APFS file system is still case-insensitive by default...

That explains things. I also couldn't make a git commit for the name change actually and was wondering why that is.

[eaplatanios]

This passes tests so I'll move on to fixing #137.