Swift for TensorFlow - dyld: Symbol not found: _$sSly7ElementQz5IndexQzcigTq - swift

I'm trying to work through the model training workflow tutorial (https://www.tensorflow.org/swift/tutorials/model_training_walkthrough) but when running the code (it's a MacOS app) in Xcode 10.2 (on MacOS 10.14.4 ) I get the following error:
dyld: Symbol not found: _$sSly7ElementQz5IndexQzcigTq
Referenced from: /Users/Luke/Library/Developer/Xcode/DerivedData/ANN-ffxhvyujcitzkqfhbrwqjnpftijw/Build/Products/Debug/ANN.app/Contents/MacOS/../Frameworks/libswiftPython.dylib
Expected in: /usr/lib/swift/libswiftCore.dylib
in /Users/Luke/Library/Developer/Xcode/DerivedData/ANN-ffxhvyujcitzkqfhbrwqjnpftijw/Build/Products/Debug/ANN.app/Contents/MacOS/../Frameworks/libswiftPython.dylib
I've followed the official installation instructions (https://github.com/tensorflow/swift/blob/master/Installation.md):
Downloaded the latest release "swift-tensorflow-RELEASE-0.2"
Run the installer
Set the toolchain to "Swift for TensorFlow Release 0.2" created 02/03/2019
Set the Build System for shared and per-user to Legacy Build System
Set Swift Compiler - Code Generation -> Optimization Level to Optimise for Speed [-0]
added libtensorflow_framework.so and libtensorflow.so to Linked Frameworks
Added "/Library/Developer/Toolchains/swift-tensorflow-RELEASE-0.2.xctoolchain/usr/lib/swift/macosx to Runpath Search Paths. $(inherited) and #executable_path/../Frameworks were already present in the list
added -lpython to Other Linker Flags

I found this to be quite helpful: https://github.com/tensorflow/swift/blob/master/Usage.md#mac-only-xcode
On macOS Catalina, Verify Code Signature for Swift for TensorFlow toolchains produces a code signature error. This prevents Xcode projects built using Swift for TensorFlow toolchains from running. To work around this issue, go to Project Target Settings > Signing & Capabilities > + Capability > Hardened Runtime and check Disable Library Validation.

Related

XCode 14 - Minimum deployment target for SPM package

I am actually compiling for macOS 10.12, as stated. I import the Reachability.swift package, that is compatible down to 10.9. No minimum version is indicated within the Package.swift file. However, I get this error while compiling :
Compiling for macOS 10.12, but module 'Reachability' has a minimum
deployment target of macOS 10.13
It happens since I updated to XCode 14, with version 13, there was no problem.
If I specify the minimum version in the Package.swift of Reachability platforms:[.macOS(.v10_10)],, I clean all the caches, I get the same problem.
I could probably upgrade deployment target to 10.13 (same computer compatibility) or simply include the Reachability.swift file in my code, but I would rather that it works...
[EDIT] Note : other packages, like AppCenter, do not have the same problem… which is weird.
[EDIT 2] With the release of XCode 14.1, the problem remains the same.
Do you have any suggestion ?
I can reproduce your problem: Using AppCenter is OK, but the reachability throws an error.
Here is what I found and maybe this is the root cause:
Make Reachability a local SPM, and modify its swift-tool-version settings and platform settings to align with AppCenter.
Then if you click into the .v10_12 MacOSVersion, you will find os versions lower than 10.13 has all been marked as unsupported
If you head to the built files, test it with otool, you will find the built product's minimum supported version matches with the above description:
So even if you specify the minimum support version to 10.12, the build tools will still target 10.13.
If you check LC_MIN_VERSION_MACOSX on AppCenter. It is also targeting 10.13 instead of 10.12 in its package.swift file.
But why Xcode accepts AppCenter and raise an error for Reachability?
Check the build log below. You will find it in the emitting module stage, the build system is using swift-frontend to embed those 3rd party dependencies. So I guess since the AppCenter is written in objective C.
The checking minimum os version behavior of swift-frontend is different between OC Dependency "AppCenter" and Swift Dependency "Reachability."

Framework not found FBLPromises (Swift Package Manager)

I've seen this problem listed elsewhere, but it always seems to be linked to a Cocoapods installation of Firebase. My problem is the opposite - trying to upgrade from pods to SPM has given me this problem when I try to compile:
ld: framework not found FBLPromises
I'm currently running Xcode 13.3 on a Mac Mini with an M1 chip, but the problem was present in earlier versions of Xcode.
Previously I had Disk (https://github.com/saoudrizwan/Disk) installed via SPM and Firebase/Messaging and Twilio (5.5.1) installed via Cocoapods. I ran pod clean and pod deintegrate, deleted all the Pod files etc and have installed Twilio and Firebase Messaging using SPM. This gives me the following Package Dependencies (and you can see that Promises 2.0.0 has been added successfully):
The top result I get when I look into this is FBLPromises Framework not found, and the second answer suggests adding arm64 as an excluded architecture, but doing that gives me further problems (warning and error below), and I'd rather not exclude an architecture blindly and then go down a rabbithole of trying to fix that when it might not be the solution to my original problem.
Warning and error when I try to exclude arm64 architecture:
None of the architectures in ARCHS (arm64) are valid. Consider setting ARCHS to $(ARCHS_STANDARD) or updating it to include at least one value from VALID_ARCHS (arm64, arm64e, armv7, armv7s) which is not in EXCLUDED_ARCHS (arm64).
error: Build input file cannot be found: '/Users/myName/Library/Developer/Xcode/DerivedData/project-exchrqebmyccatebeoxupvxpdsul/Build/Products/Debug-iphoneos/project.app/project' (in target 'project' from project 'project')
I've not checked to make sure I've not introduced other errors further down the line, but I think the problem was caused by Linker Flags being retained in the build settings.
I went to the Target -> Build Settings -> Linking and deleted everything under 'Other Linker Flags' (OTHER_LDFLAGS is how this is reflected in the project.pbxproj file according to my git diff).
File now compiles and runs successfully, if I find some subtle bugs later that might be caused by this I shall edit this answer accordingly!

Unable to load standard library for target arm64 error in XCode on Macbook Air M1

On new Mac with M1 chip get the error after the build of React Native app in XCode 12.4:
unable to load standard library for target 'arm64-apple-ios8.0'
failed to build module 'SciChart' from its module interface; the compiler that produced it, 'Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15)', may have used features that aren't supported by this compiler, 'Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)'
What I already tried:
Reinstall XCode;
Changed Swift Language Version;
Deleted VALID_ARCHS reference according Xcode 12 Beta 2 - unable to load standard library for target 'arm64-apple-ios14.0-simulator'
On Macbook with intel chip there are no errors with the same app. And both of my Macbook have the same swift version:
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin20.3.0
Can you help me please!
Guys if you have old React Native projects just build it on Xcode with rosetta and you will save your nerves and time. I was looking the decision all week, but in the total it was so easy, just run Xcode with rosetta on M1: please try to open Xcode through Rosetta - Right click on Xcode in applications folder -> Get Info -> set Open with Rosetta to true

Swift Package Manager - How to `Always Embed Swift Standard Libraries`?

We have CLI tool written in Swift for common usage (Android and iOS developers) on macOS.
Android developers without Xcode installation get the following error:
dyld: Library not loaded: #rpath/libswiftCore.dylib
Referenced from: ~/git/myClITool/macosBin Reason: image not found
Abort trap: 6
We found that enabling Always Embed Swift Standard Libraries in Xcode would most likely help, but this CLI tool is exported with SPM, ignoring all Xcode settings.
How can I achieve this build behaviour using SPM only?
Found the following commandline argument: --static-swift-stdlib
Example usage:
swift build --static-swift-stdlib -c release
This would have produced the output we were looking for. Unfortunately since Swift 5, this argument no longer works for any platforms.
When used, SPM throws the following warning:
warning: Swift compiler no longer supports statically linking the
Swift libraries. They're included in the OS by default starting with
macOS Mojave 10.14.4 beta 3. For macOS Mojave 10.14.3 and earlier,
there's an optional Swift library package that can be downloaded from
"More Downloads" for Apple Developers at
https://developer.apple.com/download/more/
Related Swift bugticket: https://bugs.swift.org/browse/SR-648

Swift 3.1.1 compile error: unknown key 'SwiftImportAsNonGeneric'

Some time after upgrading to Xcode 9, I discovered that I was no longer able to build a Kitura-based project with the Swift 3.1.1 snapshot (which I have installed via swiftenv).
When I ran swift build, some time into the build I would get:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.apinotes:8:28: error: unknown key 'SwiftImportAsNonGeneric'
SwiftImportAsNonGeneric: true
^
<unknown>:0: error: could not build Objective-C module 'Foundation'
It seems that there is a dependency between Swift and Xcode, and Xcode 9 is no longer fully compatible with Swift 3.1.1 (or earlier) snapshots. I believe it may be because my project uses Foundation, and Foundation on Mac is provided as part of Xcode, whereas on Linux it is part of the Swift snapshot (via swift-corelibs-foundation).
I did find a solution to this problem: If I keep a copy of Xcode 8.3.3 around (eg. in /Applications/Xcode8.3.3.app) then I can use sudo xcode-select -s /Applications/Xcode<version>.app/Contents/Developer to select the appropriate one prior to building with SPM, and I can then build both Swift 3.1.1 and 4.0 projects on the same system.
However, this feels a bit clunky. Each time I build a project with the 'other' Swift version, I have to make sure I run xcode-select, or the build will fail. Is having multiple versions of Xcode the right solution in this case, or am I missing a trick with Xcode 9?
note that if, like me, you upgraded Xcode via the App Store, previous versions of Xcode are still available from https://developer.apple.com/download/more/