5 ms·

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

by 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
      Yeah it's nice when it's an apt install away. Not so nice on Windows or macOS. While Go supports it all out of the box.
      - beagle3 6y ago
        But do note the apt-get doesn’t get you far. You now have a compiler that can produce .o, but headers, libraries, borked make files that are unaware of cross compiles etc are still a problem. Not so with Nim.
- 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 ? ;)

by 05 6y ago

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
    Yeah it's nice when it's an apt install away. Not so nice on Windows or macOS. While Go supports it all out of the box.
    - beagle3 6y ago
      But do note the apt-get doesn’t get you far. You now have a compiler that can produce .o, but headers, libraries, borked make files that are unaware of cross compiles etc are still a problem. Not so with Nim.
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 ? ;)