Way Cross Compile C/C++ Code to Run on Windows, Linux, and MAC Os

Way Cross Compile C/C++ code to run on Windows, Linux, and Mac OS?

You can cross compile with what is known as a cross-compiler. Mingw can be installed as such. I believe MacOS just uses g++ so you can probably make a cross compiler for it as well. Never done it myself. You can scour the web for directions. Here's the top link I got from google:

http://linux.bytesex.org/cross-compiler.html

How to Compile for OS X in Linux or Windows?

There appears to be some scripts that have been written to help get you set up cross compiling for the Mac; I can't say how good they are, or how applicable to your project. In the documentation, they refer to these instructions for cross-compiling for 10.4, and these ones for cross compiling for 10.5; those instructions may be more helpful than the script, depending on how well the script fits your needs.

If your program is free or open source software, then you may wish instead to create a MacPorts portfile (documentation here), and allow your users to build your program using MacPorts; that is generally the preferred way to install portable free or open source software on Mac OS X. MacPorts has been known to run on Linux in the past, so it may be possible to develop and test your Portfile on Linux (though it will obviously need to be tested on a Mac).

C++ cross platform compiling

It is much easier to compile it on the target OS than cross compiling it. What you need is a toolchain for every OS and a "make" tool. CMake has powerful crosscompiling abilities. This is not a necessity, but it will save some money: Get virtualization software (e.g. VMWare Player is free) and run on a different OS.

I would recommend clang (OSX), gcc (Linux), TDM gcc (Windows) as toolchains (MSVC is also nice, but is not free). The difference between 32bit and 64bit should not be the problem. When you are working with different compilers, I advise you to stick to the standard by turning the most pedantic compiler flags on at each.

I would also recommend you to have a continuous integration server somewhere with one client for every OS target and architecture. This will ease the pain of incompatible changes that you make in one OS. And you will also be able to ensure installation by package manager or installer.

Just search the web for further readings on cross compilation, toolchains and continuous integration.

Creating a Cross Platform Program Using C++

If you don't have access to a Linux or Mac OSX computer, you have to cross-compile it. To do this you have to either find a existing cross-compiler, you download the source to e.g. GCC and build it your self. Do some searching from "cross compiler" (or similar) and you will find some easy to follow tutorials.

If you do have access to a Linux or Mac, then just copy the code and build it in that environment. Be careful with Linux through, as different distributions have different versions of some libraries.

And finally, there are environments such as Wine which will allow Windows programs to run on other platforms.

Cross Platform C?

An executable has a specific format (e.g. ELF) and architecture (e.g. x86). Thus, you do have to compile multiple times. However, it is possible to cross-compile to e.g. Windows 7 x86 and Mac OS X x86 from Ubuntu. The procedures for each are different, as you would expect.

For Windows, you will want mingw32. See
Compile Windows C console applications in Linux
.

For OS X, see
How to compile Intel Mac binaries on Linux?
, which links to a tutorial.

You can search to find more information on each.

Clang C++ Cross Compiler - Generating Windows Executable from Mac OS X

Clang can in principle be used as a cross compiler: unlike most compilers clang/LLVM includes components (such as the codegen, assembler, and linker) for different platforms in the same binary.

However you'll run into a number of problems trying to use it as such in a production capacity:

  • You need platform libraries and headers. To generate an executable that will work on Windows you need Windows headers and Windows libraries you want to link to, either import libs if you're dynamically linking or static libs for static linking. You should be able to get these from an installation of Visual Studio.

  • Many C++ features such as name mangling and RTTI support are not complete on Windows. You'd have these same problems compiling for Windows on Windows with Clang. Windows C++ support is pretty much complete these days.

  • The LLVM project includes the lld linker, which is apparently far enough along that it can self host on x86 Windows and so might work for you as a cross-platform linker, however lld is not yet a standard part of clang distributions. Clang on OS X still uses the OS X platform linker ld by default as does Clang on Windows (link.exe). You'll need to get lld and figure out how to link with it, or find some other cross-platform linker.

  • The clang driver isn't written as a cross-platform compiler driver. You'll likely have to do a lot more hands-on work to run a cross-platform compilation. Take a look at the output of clang -###: the clang driver constructs that command for you, but you may have to do much of the same work as the clang driver by hand. And since clang gets much less testing at cross-platform compilation you're likely to run into more bugs.

  • Xcode is not going to help you with any of this. It can configure clang to build for OS X or iOS, but you'll have to manually configure cross-platform builds to Windows.

I'm relatively confident that one could cobble together an LLVM based environment to build a C "Hello, World" Windows exe on OS X or Linux, but it's not quite ready for Xcode to add a "Windows" item to the list of possible target platforms.


If you're not a compiler developer you're probably best off just copying your source code to a Windows machine and building with Visual Studio. If you are, or want to be, a compiler developer then by all means, help push Clang's cross-compilation abilities forward. I think the Clang universal driver project is exciting and I would really like to see progress continue.


I've successfully done the opposite cross-compilation: compiling a Mac OS X executable on Windows. This turned out to be quite easy to do manually on a small program, i.e. directly compiling a .cpp file.

First, Mac OS X development tools come with "SDKs" which contain all the system libraries and headers for a particular OS. The largest challenge here was figuring out how to transfer the SDK to Windows while preserving all the symbolic links in the SDK. (For some reason creating symbolic links on Windows requires elevated privileges, so after producing a tar.gz on OS X with the symbolic links I had to run 7zip on Windows as an administrator to correctly expand the archive.)

Once the SDK is available on Windows there's a single flag to tell clang where to get all the system dependencies: -isysroot. This combined with the -target flag were all that I needed to tell clang how to produce complete object files for OS X.

For linking I manually used lld, as the compiler driver didn't seem support using cross linking with lld. lld supports similar flags for determining the target system libraries.

The final step was simply copying the produced executable to an OS X machine, enabling the execute permission (Windows doesn't support the same file permissions so the execute bit doesn't get set when building) and running the result.

Writing cross-platform C++ Code (Windows, Linux and Mac OSX)

I'll address this specific function:

bool probe() {
#ifdef TARGET_OS_MAC
return probe_macosx();
#elif defined __linux__
return probe_linux();
#elif defined _WIN32 || defined _WIN64
return probe_win();
#else
#error "unknown platform"
#endif
}

Writing it this way, as a chain of if-elif-else, eliminates the error because it's impossible to compile without either a valid return statement or hitting the #error.

(I believe WIN32 is defined for both 32- and 64-bit Windows, but I couldn't tell you definitively without looking it up. That would simplify the code.)


Unfortunately, you can't use #ifdef _WIN32 || _WIN64: see http://codepad.org/3PArXCxo for a sample error message. You can use the special preprocessing-only defined operator, as I did above.


Regarding splitting up platforms according to functions or entire files (as suggested), you may or may not want to do that. It's going to depend on details of your code, such as how much is shared between platforms and what you (or your team) find best to keep functionality in sync, among other issues.

Furthermore, you should handle platform selection in your build system, but this doesn't mean you can't use the preprocessor: use macros conditionally defined (by the makefile or build system) for each platform. In fact, this is the often the most practical solution with templates and inline functions, which makes it more flexible than trying to eliminate the preprocessor. It combines well with the whole-file approach, so you still use that where appropriate.

You might want to have a single config header which translates all the various compiler- and platform-specific macros into well-known and understood macros that you control. Or you could add -DBEAKS_PLAT_LINUX to your compiler command line—through your build system—to define that macro (remember to use a prefix for macro names).



Related Topics



Leave a reply



Submit