Why is building a cross-compiler harder than building a regular compiler?

Question

Everything I've read seems to imply that building a cross-compiler is significantly harder than building a compiler that targets the platform it runs on. Is this true? If so, why? It seems like generating assembly code and system calls for an arbitrary platform shouldn't be any harder than generating such code and system calls for the platform the compiler is running on, but maybe I'm just being naive.

Answer 1

Is it possible that you're looking at a specific case like 'building GCC as a cross compiler', where 'building' means 'compiling' rather than 'writing'?

That might be harder because of issues surrounding libraries - for the cross-compiler you need libraries for the target platform. For the 'native' (i.e. non-cross) compiler, you clearly already have target libraries.

I'm with you on the 'creating a code generator' aspects being the same - or at least being more affected by the architecture of the target processor than by where the compiler executes.

And there are clear situations where a cross compiler is much easier than a non-cross one. I think an 8051-hosted C++ compiler would be hard-work, whatever platform it targetted.

Answer 2

This doesn't have to be harder, but it can be depending on the compiler architecture.

A compiler is not only translating source code into asm and system calls. It's also integrating pre-existing helper code into the generated files. This is code includes startup code, functions preamble, part of the C api that can be inlined, etc.

In a normal compiler C1 for platform A built on platform A, the original compiler C0 can build C1 and its helper code (for A, since C0 targets A) directly.

In a cross compiler C2 for platform B built on platform A, the original compiler C0 must first build a special version of C2 which doesn't need the helper code (because the helper code is for B, while C0 targets A), then it must run C2 to generate the helper code. Depending on the compiler, it may then have to generate a second version of C2 that includes the helper code.

The act of building the limited version of C2, without helper code is the bootstrapping.

Answer 3

This answers for the following question may help you out in understanding why this would be hard.

http://stackoverflow.com/questions/545455/why-cant-we-create-programs-cross-platforms-these-days/545528

I feel it all comes down to different operating systems calling native IO in different ways. To build a platform-independant compiler you're going to have to know exactly how all the nitty gritty works and basically build an OS.

[I will update when I get home as I have to depart work now]

Answer 4

Many cross compilers have multiple targets. I think in general a multi-target compiler is much harder than a single target compiler, and all multi-target compilers are by definition cross compilers. Therefore many cross compilers are much more complex than non cross compilers.

Writing a compiler on platform A that compiles code only for platform B shouldn't in principle be any harder than writing a compiler on platform A that compiles only for platform A.

Answer 5

"building a cross-compiler is significantly harder than building a compiler that targets the platform it runs on."

The problem exists due to the way libraries are built and accessed.

In the normal situation all the libraries are located in a specific spot, and are used by all apps on that system. All the build mechanisms and software assumes the location of the libraries. the make files, compilers, etc depend on the idea that they can go to a specific spot and find what they need.

In the cross compiling case, though, the cross compiler, make files, etc cannot make these assumptions - if they do they will link the wrong libraries.

So it really comes down to the fact that developers made certain assumptions early on, and we're stuck with that.

It gets harder when you're building root file systems, since unix only knows about one root file system. When you build another root filesystem you have to create a special environment that allows you to manipulate it without affecting the real root filesystem.

Answer 6

Building a cross-compiler is hard only if it never occurs to you that you might want to cross-compile. The same is true, interestingly enough, of assemblers, linkers, and debuggers. All you need to do is remember to create an explicit abstraction to represent what you know about the target machine.

For an example of a very well designed, well documented cross-compiler, check out lcc. To read about the design of a cross-debugger, there is a conference paper and a doctoral dissertation. The code may be downloadable; I'm not sure.

Answer 7

Here are some of the issues I've come across working with GCC cross-compilation:

• You have to have some of the system files from the target system present on the host system (i.e., a sysroot) in order to link against.

• Some languages require things to be evaluated at compile-time rather than at runtime; furthermore, some optimizations result in evaluating things at compile-time that would (in the unoptimized case) be evaluated at runtime. When the target has numerical types that are not present on the host system, it can be tricky to get the same answer in the compile-time and runtime cases.

• Testing can be a wee bit more annoying. You have to have two systems, and a way to transfer the program from one to the other.

Really, though, that's about it for general problems that I've run into.