I wonder if anyone ever tried to port Swift on Synology's own Linux based system DSM 6.2. I own a DS218 which is a pretty good NAS capable of running custom things and I'd really like to run Swift web apps on it.
3 Likes
I haven’t actually done this but I’d prolly just go through Docker on it.
I think docker is not supported on arm64 architecture.
Ah I see. I have a DS218+, and run Homebridge through it over Docker. I didn't realise the non-plus one wasn't an Intel chipset.
Docker only runs on DS218+ (Docker - Add-on Packages | Synology Inc.). I was stupid enough to buy a DS218j (it even has just a 32bit processor), but I will buy a DS218+ as well. Is Swift running there in Docker?
Swift works pretty well in docker on my DS718+ by the looks of things 
(Ignoring the no so great synology UI terminal experience anyway)
2 Likes
No other option remained for the rest but porting Swift to DSM. It is possible but a long way to go as the Linux underhood is a stripped down Debian.
It looks like the DS218 is ARM-based – it might work with the Swift on ARM docker images I maintain. I've never tested with a Synology, but I'd love to know how it goes if you try it out 
I downloaded ARMv7 version for Debian Stretch from uraimo-s github page but I got error upon executing swift binary
bash-4.3# ./usr/bin/swift --help
bash: ./usr/bin/swift: No such file or directory
Next time I will check it out with other binaries.
Almost all other variants failed with the same error :/ I see no easy way for getting Swift onto DSM.
Well, I suspect you did not get this error upon executing the swift binary. Instead you never executed the swift binary, and that is what the error is conveying.
Check again where you extracted the toolchain to, and make sure to use an appropriate relative/absolute path to the binary or add the bin directory from the toolchain to your $PATH variable.
A swift binary that is executed but can not run on the current system will fail in a different way.
I'm not exactly following you. I unpacked the tarbal and attempted to run swift like cd <unpacked tar>; ./usr/bin/swift. I also amended PATH to include usr/bin, got the same result.
Unfortunately DSM lacks tools like file to tell what's inside the binary.
Ok, it looks like we are having architecture mismatch. For instance, Debian Stretch tarball contains 32 bit binaries
file usr/bin/swift
usr/bin/swift: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=d3e3bd54bf65b11cef75011e5f67ac85f54e3cc8, not stripped
but the OS I want to run Swift on is actually a 64 bit architecture. It explains a lot.
Getting closer! I downloaded swift-5.1.3-aarch64-RELEASE-Ubuntu-18.04_2019-12-20.tar.gz, then attempted to run swift
**segabor@Szokasos** : **~/swift** $ ./usr/bin/swift
./usr/bin/swift: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
So this library keeps me away from running swift (at least I hope so).
I believe that dependency was removed in recent versions of Swift 5.2 for Linux, so you should try those versions.
If you have docker installed – give this a try.
docker run -it --rm wlisac/aarch64-swift:5.1-build swift --version
You should see something like this:
Swift version 5.1 (swift-5.1-RELEASE)
Target: aarch64-unknown-linux-gnu
Ah, my bad, I didn't know you'd also get that error message for architecture mismatches. It seems like this is caused by a limitation in the Linux syscall used to run files (see here for some more information).
I'm afraid Docker is supported on ARM based DSMs.
We are only one issue away from getting 5.2 builds. Can't wait to grab it.
I know this is an old topic but probably there are Swift fans wanting to run their code on an ARM based Synology NAS.
I was able to install Docker on DSM 7 (arm64) by following this https://cynarski.eu/docker-on-synlogy-32bit/ and run Swift REPL in 5.4 container. So far so good.
Building projects is another challenge, the container is unable to resolve github.com domain name in order to retrieve dependencies. This is an issue on Docker side (no default networking is set).
2 Likes