I'm confused by the build process for Swift on other platforms.
Does Swift allow me to build a Linux project on OS X, or do I need to use Swift specifically on Linux to to build anything I plan on using there?
I looked at the documentation, but it's not really clear on this topic...
A pure Swift application which is not importing any framework can now be compiled for iOS, OS X and for Linux.
You will generate different executables, because it's different platforms, but the code source can be the same, it just has to be compiled for the respective platform.
The difference is when you import frameworks.
If you import UIKit to make an iOS application, obviously you won't be able to compile this on Linux, because Linux doesn't have those iOS UIKit libraries, they're only available on a Mac via Xcode.
If you import Cocoa to make an OS X application, the same logic applies, it works only for OS X.
The same way, you can make Swift code that only works on Linux if you import specific Linux libraries, like Glibc, that won't work on the Mac.
Etc, etc.
What you need to remember is that the programming language isn't that relevant when it comes to make applications for a platform, it's the frameworks and libraries that you're linked to that are decisive.
Different Swift versions come with different compilers (different toolchains, actually) so to answer directly, no you can't compile for Linux Swift with the normal OS X Swift compiler, you have to use the Swift.org's one.
The Swift Package Manager got custom toolchain support via
PR-1098
end of April 2017.
This allows you to setup cross compiler toolchains (macOS to Ubuntu, even the reverse).
The SwiftPM repo contains an example script which sets up a Intel-macOS => Intel-Ubuntu toolchain.
As Eric says, you can of course only use frameworks available on the target platform. But yes, you can now build a Linux Swift project on macOS. (as mentioned by joels in the comment you can also do this via Docker very easily)
Related: (Cross-)Compiling Swift for Raspberry PI
Update 2021-10-19: There are ready-made cross compilers available as a Homebrew tap: SPMDestinations
Related
I have an XCode project with SWIFT programming language, I would like to build it on Linux.
How can I build this project on linux?
Thanks
You cannot directly use the xcode project on linux.
You can run swift on linux so you can copy the swift files from the xcodeproject and build them after installing swift compiler on linux. Also, UIKit is not available on linux so you cannot use any code that needs to import UIKit. Foundation is available but it is not completely available eg. NSJSONSerailization is not yet available on linux.
I've read that mingw can be used on Linux to build a windows executable from C/C++.
Can other languages do this, and how about popular GUI libraries?
In particular I'm interested in OCaml and Haskell as languages and libSDL, wxWdgets, and GTK as libraries.
It doesn't matter whether the language has support - what matters is the compiler (unless you're using a WORA language like Java). To answer your question, it is possible to build a cross compiler on Linux to target the Windows platform. SDL, wxWidgets, and GTK all have Windows versions to my knowledge, but you have to compile them with a compiler targeting Windows to be able to get object code that can run.
Cross compiling is very messy because you need to have one copy of a library of each architecture and platform that you want to target, and they all have to be installed in different places, so you need to play with linker flags a lot.
Here's a blog post explaining how to get a GCC distribution for Linux targeting Windows. And regarding Haskell and OCaml, sadly I'm not knowledgable in these areas, but the general case will hold true.
I have source code for a linux application. It seems I can compile it on windows with CygWin. My question is, after compilation, can I run it on Windows?
Depends totally on what APIs you use. If you stick to C standard library things, like <stdio.h>, <stdlib.h>, etc. then yes, you can just compile and run on either OS. Or for C++ apps, there is the Standard C++ Library, which any OS / development environment should provide.
If you use any OS-specific APIs, then of course it will not be compatible with another OS. There are libraries however, like APR that try to abstract out the OS-specific bits.
From a casual glance at the code you've linked to, it appears to not use any OS-specific APIs. However:
Note that this code requires the Gnu Scientific Library, http://www.gnu.org/software/gsl/
you'll need to get that library installed as well.
The simple answer is yes; if you can compile a Linux application with Cygwin, then the compiled application will run on windows. Cygwin provides windows implementations of many unix system functions and libraries.
Cygwin/mingw(http://www.mingw.org/) should have most of the tools you need to build the binary. Once the build succeeds, you can run the binary (only) on windows.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
Just today i checked my ubuntu with installing wine in it ,
Delphi 3 to 7 worked perfectly (Rad studios did not work because they use .net scraps).
But all of the application i made worked perfectly!!!!!
And i heard that it also works well in mac with WineBottler
Is it possible to create a header linux executable and put my vcl application and requird wine stuff into it and distribute as a single executable (.bin)
there is(was) a solution for Linux from Borland, called Kylix. Kylix is based on some older Qt-stuff.
But I would give FreePascal/Lazarus a try, it's pretty cool! and the compiler compiles for many different platforms.
I guess this is what winelib is for. However I have never tried it. (Wasn't Kylix Delphi + winelib compiled for Linux?)
Since Wine is now stable (reached the 1.0 version some time ago), it could make sense to ask the user to install it using its Linux packages manager. It's very fast and easy. So Wine will be always up to date, according to the distribution used.
Then it's very easy to install any Windows program with Wine.
Since Delphi executables are mostly self-contained (if you don't use the BDE or some external database libraries), your clients will install your Delphi application alla "Windows" way, that is, by running a Setup program from Wine.
And it will work fine, as is.
Using WineLib is not a good idea, even not advised by Wine developers, as far as I remember. At least for closed-source software: in one or two years, perhaps you won't release another version of your program, but Wine and WineLib will have evolved a lot... If you use Wine as an external package, your client can be sure there will be some end user enhancements.
If your software is purely Open Source, then using WineLib could make sense. But even the WineLib headers can evolved, so perhaps your source won't evolve at the same speed...