Hacker News Reader

Comment by colanderman | Hacker News Reader

I did this once with GCC.

"But GCC's open source!" you say.

Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM; and GCC maintainers insist on precise test cases to vet a bug, even if the issue is immediately obvious from reading the source code and the bug only occurs in certain very complex situations.

(/me looks forward to the day Clang/LLVM becomes the default on Linux…)

View on HN

> Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM;

You're exaggerating. I had no problems compiling gcc 3.something targeting MIPS-I on an x86 Linux host.

I can't tell if you're being sarcastic. Generally, compiling GCC to target another architecture involves not only recreating most of the root directory structure (notably include files) of the target on the host, but also compiling libc, bintools, and a few other more obscure libraries. And this all needs to be done in the correct order (which involves something like compiling half of libc before compiling GCC, and compiling the rest of libc afterward).

Maybe in 3.x and MIPS it "just worked". My experience is 4.x and Tilera. Myself and another engineer dumped a week into that sinkhole before giving up.

Clang/LLVM on the other hand… ./configure && make && make install. No other wacky dependencies or build steps. And it generates better code in many cases (particularly when dealing with structures).

Depends on the approach.

In some distributions, say, Debian, there are readily available cross-compiler packages (like g++-4.4-arm-linux-gnueabi). I haven't rebuilt gcc, but the approach must be to pull package's source, add a patch and run the build - then debian/rules and myriad of various helper scripts will take the hassle of doing everything. Just can't be the other way since package builds are automated.

And there are other tools, like buildcross that also automate the job.

> I can't tell if you're being sarcastic.

I'm not. The process is well described, it tells you exactly prerequisites, in which order to build them, and how to configure the directory structure for building gcc itself.

It worked for me the very first time I tried it.

Though I needed only a freestanding implementation, so I didn't bother with compiling libc. I believe that cross-compiling libc can be painful.

Have you tried to use buildroot ? http://buildroot.uclibc.org/

Unfortunately this had to cooperate with an existing root environment on the target, so buildroot (as fantastic as it is) was not an option.

There are scripts that do this for you, but yeah it's still a bit wonky. Also, unless you're talking about some completely unexplored target architecture, there are entire root filesystems available already for cross compilation.

I tried to compile GCC for ARM (from X86 Windows), and it was a nightmare

> Windows

> nightmare

Not exactly sure what you were expecting. GCC on Windows is already wonky enough (MinGW? MinGW-w64?), I have no Idea how one can voluntarily try compiling GCC on Windows, let alone a cross compiler.

Back in the day, crosstool was a solid way to build cross-compilers:

http://kegel.com/crosstool/

I haven't really kept up with the latest stuff, but I've seen mentions of crosstool-ng, which may be a newer take on it:

https://github.com/diorcety/crosstool-ng

So, no, it's not next-to-impossible. It's a little complicated, and that's why these projects exist, but my memory of crosstool was that it made it trivially easy: run the script, let it compile for a bit, and voila, you now have a brand-new cross-compiler toolchain.

I've used crosstool-ng as recently as 8ish months ago, so I will agree: it's not even remotely next-to-impossible but instead very very possible, and, I'd venture to say, almost easy.

Cross-compiling and Canadian-cross isn't fun but isn't that bad. There are good projects out there to help in the process. http://crosstool-ng.org/ is a good project that can make it much easier. They have Canadian-cross support but I haven't used it.

Just recently I wrote https://github.com/ikonst/LongPathFix to work around a clang/gcc issue, cause it seemed easier than going through the hoops of building clang for Win32, understanding its code and writing a patch good enough to be accepted.

Reply on news.ycombinator.com