I'm using QT Creator on a project and was wondering if there's a single command to compile the project to a Mac, Windows, & Linux binaries so I can easily send them to other computers for testing without having to send over the whole source code. Currently I'm running the QT Creator on Mac OSX if that matters.
This is possible, but it isn't as simple as you imply. To properly do this, you would need to set up a cross-compiling environment complete with libraries already compiled for the other platforms, and compilers/executables compiled for your platform that produce output for the other platform. You would then need to keep track of all these variables somehow in your qmake file to be sure you're producing the correct output.
Related
I have generated one FMU on Windows, and imported the FMU on Mac using Matlab Simulink, and got the following error. I searched for the problem and get some clues from the answer here
https://tomlankhorst.nl/quick-fix-matlab-fmu-import-error/, it seems like FMU will be stored as different form when generated on Windows and Mac.
the question is: is it possible to generate a FMU on windows that still works on Mac.
In order to compile for MacOS, you need the C headers for the MacOS platform. These are only available in XCode which only runs on MacOS and the headers themselves are not allowed to be redistributed.
As such, it's pretty hard to cross-compile for MacOS. You can install XCode on your Mac, move the required headers to your system and compile a Darwin toolchain on your Windows machine (I believe), but it's very error-prone and annoying to update for newer MacOS versions.
The easiest way would be to run MacOS and cross-compile Windows+Linux binaries since these platforms are less closed.
Or like #matth commented, generate a source-code FMU and compile that using the native toolchain on any platform you need.
My coworker and I are both using Go 1.9 x64. I'm running Linux Mint 18.2 and he's running macOS Sierra 10.12.6. We ran the exact same script to cross compile a program for Windows x64 and out of curiosity we diffed the files to see how similar they would be. We expected to find a few build parameters or IDs to be different but it turns out there are a LOT of differences all throughout the files.
We made sure the two programs were built off the exact same code. The program really doesn't do anything too OS specific. It reads a JSON file and executes a series of web requests determined by that file. Nothing like executing shell commands or reading/writing the windows registry. No CGO, the only use of the os package is os.Exit(code) calls, nothing stands out as a culprit.
Even though the programs were built from two different host OSes, they were both built for the same target OS with the same version of the Go compiler and the same code files. Why are the output binaries so different?
I was following instructions here and here to build a toolchain which would work on Windows and compile applications for Linux and different hardware platforms. At first I tried to create cross-compiler for i686-linux to test it on a generic Debian 8 system.
Binutils and GCC compiled fine, but I got stuck at Glibc. It told me:
*** The GNU C library is currently not available for this platform.
I see that Sysprogs toolchains are using Newlib instead of Glibc but I haven't found any explanations except that Newlib is a good choice for embedded devices.
Does it mean that Newlib is actually the only choice for Windows -> Linux and that there is no way to compile software which depends on Glibc? Maybe there are "cheats", like copying pre-built Glibc from the target platform or some other workaround?
In theory, I don't even need Glibc built on Windows, I need just some "Glibc compatible stub" built for the target architecture to link (only dynamically, of course) against while compiling for the target platform and OS. Or am I totally wrong here and GCC cannot link to a different C library than GCC itself was linked to?
Or should I forget it and accept the fact that it is impossible (and, most probably, never will be possible) to achieve full Glibc and Linux kernel compatible C/C++ cross-compiling from Windows to GNU/Linux?
I will accept the answer which explains how GCC and Glibc are related and whether it is possible or not to link against Glibc different from C library used when GCC itself was built, and provide some insight about why it is / is not possible.
my guess is you're using --target when building glibc when you really need to use --host (which is different from how newlib is configured -- best to not ask why).
that said, the glibc build system requires a case-sensitive file system as it creates files like foo.oS and foo.os which are very different things. on a system like Windows, that means the build will be corrupted and fail since foo.oS and foo.os refer to the same file. there are patches out there to hack around this, but really you'd be better off booting a VM and doing the toolchain build inside of that.
NB: i'm not saying you need the VM to do all your development. you just need the VM to build the cross-compiler which you'd then run under Windows. this would be a canadian cross build.
rather than do all this yourself by hand, please check out crosstool-ng. it handles/patches/fixes a lot of common errors people make when trying to create cross-compilers.
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
I am trying to compile lanshark for mac, but do not know how to compile on mac. I am guessing that it is possible to compile linux source code on mac. if not how can i get this program to run?
A mac is, under the hood, a BSD 'darwin' box.
Go and take a look at the MacPorts webpage. You'll find lots of interesting information (like where to get a compiler etc ) there.
Another place to go for an apple development environment is apple (xcode) ...
It should be possible to get that to run, but it will be a bit of work. The source may need a small amount of modification, depending on exactly how the protocol works (if they're using raw ethernet, that is done quite differently). Also, the OS X linker (ld) works completely differently to the Linux linker, and so the build system will need a bit of tinkering.
However, the compilers and build utilities are in the XCode bundle on your install disk, or at the download link in the other answer, so install that and give it a go. If you're lucky, just following the Linux instructions will build it.