9 ms·

Hopefully the pains we feel with this shift to arm will inspire compiler developers to take cross compiling seriously. I don't see a reason why a compiler can't

Hopefully the pains we feel with this shift to arm will inspire compiler developers to take cross compiling seriously. I don't see a reason why a compiler can't output binaries for any (or even ALL supported) platforms with a single CLI flag like golang does.

SheinhardtWigCo 6y ago
Good thread on this from 2018: https://news.ycombinator.com/item?id=18732832 https://news.ycombinator.com/item?id=18732832
05 6y ago
Golang can do this for the single reason of having no runtime dependencies whatsoever. Try it with literally any other language and you quickly find out that it’s no use crosscompiling to armv7 ‘in one click’ when your target doesn’t have the version of libc you’re targeting. The problem is not the compiler, it’s the build tooling.
- beagle3 6y ago
  Zig and Nim both have excellent cross compiling support out of the box. Zig extends that excellent support to its embedded LLVM C compiler - it’s probably the easiest way to cross compile C across operating system boundaries these days.
  - sim_card_map 6y ago
    https://nim-lang.org/docs/nimc.html#cross-compilation https://nim-lang.org/docs/nimc.html#cross-compilation Nim doesn't seem to have excellent cross compiling support out of the box. It simply relies on cross platform toolchains that you have to set up. Good luck setting up cross platform GCC. Zig uses musl AFAIK? That can often be problematic.
    - audunw 6y ago
      Zig supports musl, glibc, macOS libc, and mingw I think: https://ziglang.org/download/0.7.0/release-notes.html https://ziglang.org/download/0.7.0/release-notes.html But yeah, I think musl is the main target, and it ships with the source for it
      - sim_card_map 6y ago
        But it only uses musl for cross compilation, no? I don't think it uses glibc to compile Linux binaries on macOS or macOS libc to compile macOS binaries on Linux.
        Gaelan 6y ago
        musl is a Linux libc, so you can't use in on any other OS (because it wouldn't know how to send syscalls to the kernel). macOS handles libc a little differently from Linux; whereas the Linux kernel publishes its syscall API, and allows programs to make syscalls however they want (e.g. with glibc or musl, or with go, which does syscalls itself), macOS's syscall API is subject to change at any time, and the only (supported) way to make syscalls is to dynamically link to the system libc.
        zeeboo 6y ago
        It can target glibc in a cross-compile setting. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
    - beagle3 6y ago
      Nim always relies on an underlying platform compiler. Getting an .o out from a cross compiler is easy, in my experience - the big problem is getting libraries, includes and linkage right. And in my (admittedly small) experience, Nim makes that part much simpler as soon as you have a compiler set up (which in my case was an apt-get away)
      - sim_card_map 6y ago
  - benibela 6y ago
    FreePascal works well, too, once it is installed To compile to linux it needs to have a linker installed. For windows it has an internal linker, so probably does not even need that
- kelnos 6y ago
  Can it do this anymore on macOS? My understanding was that they were going to start linking to libSystem, as they should, because otherwise golang apps can and will break between major macOS releases. (Not to mention the golang folks' need to reinvent the wheel has caused a few high-profile bugs that have needlessly wasted people's time.) Regardless, this quickly falls apart whenever you have an app that does any kind of FFI to system libraries, or even third-party libraries that the author didn't want to reimplement in golang.
  - bpye 6y ago
    FFI can work - P/Invoke with C# for example doesn't care if you're cross compiling or not, but it comes at the cost of needing a definition of the interface in your code. Windows makes cross compiling work by shipping the libs for each of the architectures in the SDK. I think that's quite reasonable for macOS since Apple controls the SDK, but it's always seemed to be a mess on Linux. Disclaimer: I work at Microsoft on Windows but I have tried cross compiling code on both Windows and Linux in the past and I've always found it painful on Linux.
  - foldr 6y ago
    You can, I think, link to libSystem dynamically without actually having libSystem to refer to. At least, you can output a macho file that calls a function in a dynamically linked library when all you know is the name of the function.
- zaphirplane 6y ago
  Even Java ? ;)
pjmlp 6y ago
Try to cross compile a UWP application from Linux into Windows. Cross compilation only works for toy examples, or when one has 100% of the target libraries available.
- coldtea 6y ago
  Or for languages with no such non-language-native dependencies, like Go, where I've found it to be piece of cake (and I've never ever tried it for C).
  - pjmlp 6y ago
    That only works for pure Go code (no use of cgo) and for Go libraries that don't call into OS APIs.
    - est31 6y ago
      You can absolutely call into OS APIs, as that's what the Go implementation does to interact with the OS in the first place. It also uses cgo internally for that task. https://github.com/golang/go/blob/2a029b3f26169be7c89cb2cdcc3db4b5d097a8b8/src/runtime/os_windows.go https://github.com/golang/go/blob/2a029b3f26169be7c89cb2cdcc...
      - pjmlp 6y ago
        Right, now try to actually use it. Specially missing entries from that list.
        est31 6y ago
        What do you mean? You use this when you use the builtin os package of Go. https://golang.org/pkg/os/ https://golang.org/pkg/os/
        pjmlp 6y ago
        Now try to use that, to call these from a Linux compiled executable, https://docs.microsoft.com/en-us/windows/win32/api/ https://docs.microsoft.com/en-us/windows/win32/api/
nly 6y ago
If anything the M1 Mac reduces the case for cross-compilation since they're actually fast enough to build code on. Compare that to e.g. compiling hefty C++ projects on the Raspberry Pi where cross compilation on a fast x86 box is ideal (but still far from trivial). For non-trivial projects you want CI anyway so it's a better ROI of your time to just to add an additional VM, Docker or native runner. And let's not forget you'll also want to run your automated tests in the native environment.

SheinhardtWigCo 6y ago

Good thread on this from 2018: https://news.ycombinator.com/item?id=18732832 https://news.ycombinator.com/item?id=18732832

05 6y ago

Golang can do this for the single reason of having no runtime dependencies whatsoever. Try it with literally any other language and you quickly find out that it’s no use crosscompiling to armv7 ‘in one click’ when your target doesn’t have the version of libc you’re targeting. The problem is not the compiler, it’s the build tooling.

beagle3 6y ago
Zig and Nim both have excellent cross compiling support out of the box. Zig extends that excellent support to its embedded LLVM C compiler - it’s probably the easiest way to cross compile C across operating system boundaries these days.
- sim_card_map 6y ago
  https://nim-lang.org/docs/nimc.html#cross-compilation https://nim-lang.org/docs/nimc.html#cross-compilation Nim doesn't seem to have excellent cross compiling support out of the box. It simply relies on cross platform toolchains that you have to set up. Good luck setting up cross platform GCC. Zig uses musl AFAIK? That can often be problematic.
  - audunw 6y ago
    Zig supports musl, glibc, macOS libc, and mingw I think: https://ziglang.org/download/0.7.0/release-notes.html https://ziglang.org/download/0.7.0/release-notes.html But yeah, I think musl is the main target, and it ships with the source for it
    - sim_card_map 6y ago
      But it only uses musl for cross compilation, no? I don't think it uses glibc to compile Linux binaries on macOS or macOS libc to compile macOS binaries on Linux.
      - Gaelan 6y ago
        musl is a Linux libc, so you can't use in on any other OS (because it wouldn't know how to send syscalls to the kernel). macOS handles libc a little differently from Linux; whereas the Linux kernel publishes its syscall API, and allows programs to make syscalls however they want (e.g. with glibc or musl, or with go, which does syscalls itself), macOS's syscall API is subject to change at any time, and the only (supported) way to make syscalls is to dynamically link to the system libc.
      - zeeboo 6y ago
        It can target glibc in a cross-compile setting. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
  - beagle3 6y ago
    Nim always relies on an underlying platform compiler. Getting an .o out from a cross compiler is easy, in my experience - the big problem is getting libraries, includes and linkage right. And in my (admittedly small) experience, Nim makes that part much simpler as soon as you have a compiler set up (which in my case was an apt-get away)
    - sim_card_map 6y ago
- benibela 6y ago
  FreePascal works well, too, once it is installed To compile to linux it needs to have a linker installed. For windows it has an internal linker, so probably does not even need that
kelnos 6y ago
Can it do this anymore on macOS? My understanding was that they were going to start linking to libSystem, as they should, because otherwise golang apps can and will break between major macOS releases. (Not to mention the golang folks' need to reinvent the wheel has caused a few high-profile bugs that have needlessly wasted people's time.) Regardless, this quickly falls apart whenever you have an app that does any kind of FFI to system libraries, or even third-party libraries that the author didn't want to reimplement in golang.
- bpye 6y ago
  FFI can work - P/Invoke with C# for example doesn't care if you're cross compiling or not, but it comes at the cost of needing a definition of the interface in your code. Windows makes cross compiling work by shipping the libs for each of the architectures in the SDK. I think that's quite reasonable for macOS since Apple controls the SDK, but it's always seemed to be a mess on Linux. Disclaimer: I work at Microsoft on Windows but I have tried cross compiling code on both Windows and Linux in the past and I've always found it painful on Linux.
- foldr 6y ago
  You can, I think, link to libSystem dynamically without actually having libSystem to refer to. At least, you can output a macho file that calls a function in a dynamically linked library when all you know is the name of the function.
zaphirplane 6y ago
Even Java ? ;)

pjmlp 6y ago

Try to cross compile a UWP application from Linux into Windows. Cross compilation only works for toy examples, or when one has 100% of the target libraries available.

coldtea 6y ago
Or for languages with no such non-language-native dependencies, like Go, where I've found it to be piece of cake (and I've never ever tried it for C).
- pjmlp 6y ago
  That only works for pure Go code (no use of cgo) and for Go libraries that don't call into OS APIs.
  - est31 6y ago
    You can absolutely call into OS APIs, as that's what the Go implementation does to interact with the OS in the first place. It also uses cgo internally for that task. https://github.com/golang/go/blob/2a029b3f26169be7c89cb2cdcc3db4b5d097a8b8/src/runtime/os_windows.go https://github.com/golang/go/blob/2a029b3f26169be7c89cb2cdcc...
    - pjmlp 6y ago
      Right, now try to actually use it. Specially missing entries from that list.
      - est31 6y ago
        What do you mean? You use this when you use the builtin os package of Go. https://golang.org/pkg/os/ https://golang.org/pkg/os/
        pjmlp 6y ago
        Now try to use that, to call these from a Linux compiled executable, https://docs.microsoft.com/en-us/windows/win32/api/ https://docs.microsoft.com/en-us/windows/win32/api/

nly 6y ago

If anything the M1 Mac reduces the case for cross-compilation since they're actually fast enough to build code on. Compare that to e.g. compiling hefty C++ projects on the Raspberry Pi where cross compilation on a fast x86 box is ideal (but still far from trivial). For non-trivial projects you want CI anyway so it's a better ROI of your time to just to add an additional VM, Docker or native runner. And let's not forget you'll also want to run your automated tests in the native environment.