21

Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?

I'm thinking something like passing a -target to the swift command and passing another parameter to let it statically link all dependencies, but I'm not sure what the exact commands are.

The exact value for -target seems to be rather elusive.

Do I need to know the exact target distribution to be able to pass the correct string to the -target parameter?

TheDarkKnight
  • 27,181
  • 6
  • 55
  • 85
hasen
  • 161,647
  • 65
  • 194
  • 231
  • 1
    Perhaps I misunderstand your question, but a linux binary (elf) and mac binary (mach-o) are [not compatible](https://stackoverflow.com/questions/9439436/is-a-linux-executable-compatible-with-os-x). – TheDarkKnight Jun 01 '17 at 08:38
  • Yes, obviously they are not. Cross compiling means compiling from one os to a different target os. For example, working form a linux box, and compiling to a windows compatible exe. I haven't done it before but I've seen people talk about doing this kind of stuff so I assume it's possible. – hasen Jun 01 '17 at 08:42
  • I didn't think this to be possible on OS X with native Apple compilers, but will watch this question with interest. – TheDarkKnight Jun 01 '17 at 09:45
  • 1
    You need to do this from a linux box, am afraid. The [github repo for Swift](https://github.com/apple/swift) shows how to build it targetting the appropriate environment. Cross-Compile is more for processor architecture, e.g. x86 -> ARM which is where it works. From your question "*compile a swift binary*" does not make sense, its already in binary form, that targets Mac OSX environment, it is not portable across to Linux. Perhaps you meant, compile the sources to swift from source. – t0mm13b Jun 03 '17 at 10:36
  • I meant compile to a single binary (without needing dynamically linked libraries to accompany the binary) – hasen Jun 03 '17 at 10:45
  • So what you want is to be able to build your swift app on one machine which is designed for another correct? – Jouster500 Jun 06 '17 at 13:59
  • @Jouster500 correct – hasen Jun 07 '17 at 02:10
  • @t0mm13b I ended up giving up and creating a linux virtual machine specifically for producing a linux build! – hasen Jun 07 '17 at 02:12
  • no no no, hold on – Jouster500 Jun 07 '17 at 02:36
  • Might this answer help? [Swift on OS X compiling for Linux?](https://stackoverflow.com/a/44003954/1107226) – leanne Jun 09 '17 at 21:27

2 Answers2

14

From reading the sources on github

  • target would be Linux
  • machine would be x86_64

This gets called by the primary build script

This how ever answers a part of the question

The exact value for -target seems to be rather elusive.

Install a GCC toolchain for Mac OSX that can retarget Linux, one repo that I can see is OSXCross, for example.

Supply the values to the environment variables to GCC prior to running the script, that references that toolchain.

Unfortunately, that does not guarantee it will work, but give it a try and see what happens.

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
1

Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?

The short answer? Of course it is! Anything is possible when you put your heart to it!

Is it efficient? Inherently, no.

While I'm sure everyone here is familiar with what a compiler does, for the sake of this question and its newest of users, a compiler is an application that converts human readable code and maps it to a binary format that a computer can understand. However it should be worth mentioning that not all computers are the same. Each computer operating system has a different binary mapping than the other so a simple operation like copying values could be expressed as 1010 on one machine, and 0101 on another. As stated before in many questions prior, and for example this one, many programming languages are buildable across a variety of machines, but very few of them are portable across them because each computer has a different binary mapping.

~~~~~~~ So how do we fix this? ~~~~~~~

  • Well there are a number of solutions to fix this. The most obvious method is to simply make your environment the target environment and build your program to your hearts content. You obviously already did this through a virtual machine and this typically what many developers will do. This is by far the easiest solution but it defeats the purpose of the question where you want to simply build from your OSX machine.

Earlier you said you heard people talking about compiling windows programs on linux machines. Cygwin is a a development platform aimed at obtaining the windows framework that is not normally present on linux machines and allows many programs to be built with the windows framework in mind. However all its doing is adding binaries so that the compiler has some proper places to map to when windows only commands are found within a configuration. All its doing is introducing the binary configurations necessary for a program to successfully be ported over. This ties into the second option.

  • Secondly comes a compiler that supports cross platform compilation. While I am currently uninformed and/or unfamiliar with such compilers, this is technically a valid solution but would I call it reliable? Probably not. If anything you're just adding more work to your compiler as not only does it have to correctly map the syntax of one computer program for one computer, it has to waste time linking it to the new binaries. Additionally you would need to have the compiler remember these linking's which could entail more wasted memory space for having this one compiler.

Even then, systems like these are few and far between and whether its guaranteed to work depends upon how well the compilers maintainer knows their stuff, how frequently they update it etc. etc. And the chances that they even performed to correct mappings of binaries in the first place is not something I'd stake my life on.

  • The third and perhaps most ideal solution is to look into container technologies such as docker. Their containers are essentially ways for you to build your app and port it to new machines without having to change or modify anything about how you build and compile it. Simply build one, store it in a container, port it to your machine of choice and integrate it into your current project. Come to think of it, container systems like docker were built to prevent the very thing that you are currently experiencing, where you have a source code working on your one machine but no place else. Something like docker will be able to run your code on any machine without having to recompile it for each new machine.

Docker provides an interesting framework for container to container communication, application examples and has a fairly straightforward documentation that it would be worthwhile to look at to see if your project could have some of its parts ported to docker.

This being said, there are multiple ways to fix the issue you are currently facing, so as you being a software engineer, its up to you in what would be the most ideal way of handling your project.

// EDIT //

Will edit this to be a better response once im not drop-dead tired.

Jouster500
  • 762
  • 12
  • 25
  • 1
    Cygwin is not for Windows apps on Linux, it's for Linux apps on Windows (btw thank for link so I didn't have to use Google ;) ) – Markaos Jun 09 '17 at 20:42
  • Also, server probably doesn't use parts of Swift which aren't available on Linux (like GUI library, I guess), so it should be efficient – Markaos Jun 09 '17 at 20:45
  • @Markaos I am aware that its not what cygwin is for. I was referring to the fact that it adds the binaries that you would need from a coding standpoint which you cant receive elsewhere. If you were a C++ coder working on linux and you wanted your app to run on windows you would need some binary packages that windows has and linux doesnt. I was under the impression cygwin fixed this. The Efficiency I was referring to is the workarounds needed to do what the original question asked of in terms of memory, time, and complexity. – Jouster500 Jun 09 '17 at 20:51