4 ms·

the compilers themselves (e.g gcc) aren't the problem typically. It tends to be the dependencies (of the compiler and the libraries) that assume target==host.

IshKebab 8y ago
Erm, GCC is a huge problem for cross-compiling, because it's compilation target is determined at compile time. I mean at GCC compile time. You have to recompile GCC to target a different machine. Clang isn't broken like that, and for clang you are right that the issue is normally dependencies. Again GNU's libc is kind of broken. Cross compiling with Clang and Musl is not too bad.
- phkahler 8y ago
  This IMHO is a huge problem for embedded development. I want to be able to just select what target I want and recompile a project. Even in small embedded systems you still need target specific headers and .bss code, but that's more of an IDE problem on top of the compiler not supporting all architectures out of the box. A C library that uses no hardware specific features should be able to recompile trivially for any supported target for example. If my chip vendor decides to replace the ARM core on a SoC with a RISC-V core but leave all peripherals and memory mappings the same, I want to simply change the target and rebuild.
  - microcolonel 8y ago
    > If my chip vendor decides to replace the ARM core on a SoC with a RISC-V core but leave all peripherals and memory mappings the same, I want to simply change the target and rebuild. I mean, I don't know what distro you're working on (and whether they package these toolchains conveniently), but on Arch you just change your configured target in your conf/build system, and make sure you have the other one installed. If you're using autotools or cmake, you may not even need to change the configure scripts. If you're doing embedded with memory mapped peripherals, surely you're building all your deps statically anyway.
  - pvarangot 8y ago
    If you are memory mapping stuff like that you most likely already have your own linker script or something from the vendor of arch1 and you can, with not much pain, adapt the linker script for arch2 to use the same base addresses and magic numbers. I mean I haven't personally done it but worked on projects were we were doing that and the headers for both archs were almost the same. If you don't have hardcoded addresses and are fully abstracted by a modern HAL and VM like on Linux then it's mostly a problem of the Linux distro or the OS vendor.
    - dbuder 8y ago
      You end up relying on the linker developer.
  - jononor 8y ago
    Does such hardware exist? Usually peripherals get an update whenever major changes are done anyways, cause that's where the value add is for most SoCs.
- ajross 8y ago
  With all due respect: clang hasn't been asked to cover even a tiny fraction of the breadth you get with gcc. Cross compiling with clang generally just means building ARM Linux binaries on x86 Linux hosts. Where's the clang/llvm equivalent to buildroot, for example?
  - IshKebab 8y ago
    The reason GCC is designed like that and LLVM isn't has nothing to do with the number of target architectures that either support.

IshKebab 8y ago

Erm, GCC is a huge problem for cross-compiling, because it's compilation target is determined at compile time. I mean at GCC compile time. You have to recompile GCC to target a different machine. Clang isn't broken like that, and for clang you are right that the issue is normally dependencies. Again GNU's libc is kind of broken. Cross compiling with Clang and Musl is not too bad.

phkahler 8y ago
This IMHO is a huge problem for embedded development. I want to be able to just select what target I want and recompile a project. Even in small embedded systems you still need target specific headers and .bss code, but that's more of an IDE problem on top of the compiler not supporting all architectures out of the box. A C library that uses no hardware specific features should be able to recompile trivially for any supported target for example. If my chip vendor decides to replace the ARM core on a SoC with a RISC-V core but leave all peripherals and memory mappings the same, I want to simply change the target and rebuild.
- microcolonel 8y ago
  > If my chip vendor decides to replace the ARM core on a SoC with a RISC-V core but leave all peripherals and memory mappings the same, I want to simply change the target and rebuild. I mean, I don't know what distro you're working on (and whether they package these toolchains conveniently), but on Arch you just change your configured target in your conf/build system, and make sure you have the other one installed. If you're using autotools or cmake, you may not even need to change the configure scripts. If you're doing embedded with memory mapped peripherals, surely you're building all your deps statically anyway.
- pvarangot 8y ago
  If you are memory mapping stuff like that you most likely already have your own linker script or something from the vendor of arch1 and you can, with not much pain, adapt the linker script for arch2 to use the same base addresses and magic numbers. I mean I haven't personally done it but worked on projects were we were doing that and the headers for both archs were almost the same. If you don't have hardcoded addresses and are fully abstracted by a modern HAL and VM like on Linux then it's mostly a problem of the Linux distro or the OS vendor.
  - dbuder 8y ago
    You end up relying on the linker developer.
- jononor 8y ago
  Does such hardware exist? Usually peripherals get an update whenever major changes are done anyways, cause that's where the value add is for most SoCs.
ajross 8y ago
With all due respect: clang hasn't been asked to cover even a tiny fraction of the breadth you get with gcc. Cross compiling with clang generally just means building ARM Linux binaries on x86 Linux hosts. Where's the clang/llvm equivalent to buildroot, for example?
- IshKebab 8y ago
  The reason GCC is designed like that and LLVM isn't has nothing to do with the number of target architectures that either support.