4 ms·

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 tar

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…)

ikonst 12y ago
Just recently I wrote https://github.com/ikonst/LongPathFix 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.
zvrba 12y ago
> 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.
- colanderman 12y ago
  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).
  - microcolonel 12y ago
    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.
  - fla 12y ago
    Have you tried to use buildroot ? http://buildroot.uclibc.org/ http://buildroot.uclibc.org/
    - colanderman 12y ago
      Unfortunately this had to cooperate with an existing root environment on the target, so buildroot (as fantastic as it is) was not an option.
  - zvrba 12y ago
    > 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.
  - drdaeman 12y ago
    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.
- maccard 12y ago
  I tried to compile GCC for ARM (from X86 Windows), and it was a nightmare
  - LeonidasXIV 12y ago
    > 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.
stusmall 12y ago
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/ 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.
davvid 12y ago
Back in the day, crosstool was a solid way to build cross-compilers: http://kegel.com/crosstool/ 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 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.
- kelnos 12y ago
  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.

ikonst 12y ago

Just recently I wrote https://github.com/ikonst/LongPathFix 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.

zvrba 12y ago

> 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.

colanderman 12y ago
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).
- microcolonel 12y ago
  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.
- fla 12y ago
  Have you tried to use buildroot ? http://buildroot.uclibc.org/ http://buildroot.uclibc.org/
  - colanderman 12y ago
    Unfortunately this had to cooperate with an existing root environment on the target, so buildroot (as fantastic as it is) was not an option.
- zvrba 12y ago
  > 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.
- drdaeman 12y ago
  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.
maccard 12y ago
I tried to compile GCC for ARM (from X86 Windows), and it was a nightmare
- LeonidasXIV 12y ago
  > 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.

stusmall 12y ago

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/ 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.

davvid 12y ago

Back in the day, crosstool was a solid way to build cross-compilers: http://kegel.com/crosstool/ 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 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.

kelnos 12y ago
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.