So I'm trying to cross compile a large project on Ubuntu x86 for ARM unix and windows x86.

Questions:

For the ARM cross compile I have to compile all of the libraries it uses seperatly before using a toolchain to compile the whole project right? If not whats the proper procedure?

For the windows compile do I need to recompile all the libraries? Or will it be fine because its using the same cpu architecture?

What will a change in os mean for the work I have to do?

What will a change in cpu architecture mean?

What will a change in both mean?

Thank you for your help.

For the ARM cross compile I have to compile all of the libraries it uses seperatly before using a toolchain to compile the whole project right? If not whats the proper procedure?

Well, no, you just need to use the ARM toolchain to build your stuff. This is basically the same as your ordinary compiler, but instead of using your system's libraries and building for your own processor architecture, it'll build for generic ARM libraries and an ARM processor. You won't be able to run the executable on your own machine, but it will work in an ARM emulator as well as a real ARM device (if done properly).

For the windows compile do I need to recompile all the libraries? Or will it be fine because its using the same cpu architecture?

Yes. Windows and Linux have different libraries and you must recompile. In fact Windows and Linux even have a different ABI for the x86_64 processor, so it's not even really the "same" processor architecture. So yes you will have to compile once for Linux, and once for Windows. In general trying to cut corners by compiling some code and not other code for a new target is bound to cause issues with binary compatibility and library references, so it's best to just recompile everything at once.

That said if you have already built independent parts of your code for a given OS + architecture, you don't need to recompile them again if nothing has changed. You can reuse them, just make sure you track them properly to make sure you are not linking to an outdated or incompatible version of your code,

What will a change in os mean for the work I have to do?

You'll need to:

1. get a cross-compilation toolchain for the new OS.

2. adapt your code to support the OS (moar #ifdef's or using cross-platform libraries)

3. run tests on one more OS

What will a change in cpu architecture mean?

You'll need to:

1. make sure your cross-compiler supports that processor architecture

2. if applicable, take advantage of that processor architecture in your code (if you're not doing inline assembly, you don't need to worry about this)

3. run tests on one more processor architecture

Note this depends on "how different" the new CPU architecture is. If you're just adding support for extra features of a processor you already support, you should be fine and there should not even be a need to recompile anything. But if you are supporting a whole new CPU with different instruction set and everything, then you must start again from scratch with that processor.

Thanks for the info. Back to the ARM compile for a second: Say the program uses Boost, will I need to recompile Boost under ARM (or a toolchain)? Or will I be able to compile the whole project using the version of boost already compiled and used in the project?

Thank you so much for the thorough response.

Thanks for the info. Back to the ARM compile for a second: Say the program uses Boost, will I need to recompile Boost under ARM (or a toolchain)? Or will I be able to compile the whole project using the version of boost already compiled and used in the project?

In general, yes, every library you use must be compiled using the same toolchain as your main project, to be able to correctly resolve system calls, making sure it's using the right instruction set (you can't run x86 code on ARM) and other stuff. A cross-platform library/program doesn't mean a binary that can run everywhere, it means a library/program you can compile relatively effortlessly for most if not all operating systems and architectures.

If you try to link your project (built against ARM) against a library (built against your computer, say x86), what will happen is:

1. the cross-compiler will complain that it can't find the entry points of every single external function called by the library because it only has access to the system libraries of the operating system you are building for, which are obviously not compatible with your own (the ones you used to build the library) since they are for different architectures and hence different calling conventions, and so on (and possibly even different operating systems)

2. the cross-compiler will complain the library is corrupted or incompatible, because it's using x86 instructions instead of ARM instructions

A good way to think about this is that when you are using a cross-compiler, your own system becomes simply a tool to run the compiler. Nothing else is used and the result of the cross-compilation must not depend on what you used to compile your project (you might as well have compiled it on a toaster - it doesn't matter because when cross-compiling the only thing your system does is run the compiler).

Well I have maybe 20 external libraries in this project. Is there any easy way to get already compiled libraries for other platforms? It takes ages to compile these libraries, and the ones that compile fast are always the hardest to use a cross compiler with.

Well I have maybe 20 external libraries in this project. Is there any easy way to get already compiled libraries for other platforms? It takes ages to compile these libraries, and the ones that compile fast are always the hardest to use a cross compiler with.

Yes. In large popular libraries there are often release builds for many platforms, which should be compatible with your toolchain. Sometimes other users might have already built them and put them up for download somewhere. Though this is more popular in the Windows world - the Linux/Unix spirit is to compile the code yourself for your system, which as you probably noticed makes cross-compiling somewhat unintuitive, because those users are not usually exposed to the concept of compiling for other platforms, whereas other users (in particular Windows users) need to deal with coexisting 32-bit and 64-bit programs and libraries which are incompatible with one another, so they often have to ask themselves the question "which one do I need" which makes cross-compiling come more naturally, IMHO.

However if the library has never been built for ARM or other platform, no, your only option is to compile it yourself, unfortunately, since it needs to get compiled somehow to be used. But again, if the library is well-known and your target system/platform is not exotic, it's very likely that it has already been built by someone and perhaps even by the official maintainers of the library as part of their release process. And if not, there are usually tutorials on how to do so for a given library.

As for the question you are probably going to ask next - yes, some libraries were not designed to be cross-platform (e.g. using hundreds of platform-specific functions and containing non-portable code) and so it would be almost impossible to port them to ARM or whatever, in which case your only option is to find another, more portable library that does the same thing, unfortunately. This is, sadly, a reality, and makes otherwise portable programs need extra work to become truly cross-platform because a dependency is holding them back. Things have gotten better, though, and such libraries are rare.

I agree it's a pain when every library seemingly uses a different build method (e.g. this one uses CMake, the other autotools, that one has a funky Python installer, and so on) but in my experience cross-compiling is something that's tedious and error-prone to set up, but works wonderfully once everything's up and running... it would be much easier if everyone would agree on a standard way to write and compile portable libraries, but you know how that works..

Thanks for the answers, I somehow avoided learning this stuff in school. You've helped me out a lot with this work.