3 ms·

This seems to imply that Go's binaries are otherwise compatible with multiple platforms like amd64 and arm64, other than the issue with linking dynamic librarie

by necovek 11mo ago

This seems to imply that Go's binaries are otherwise compatible with multiple platforms like amd64 and arm64, other than the issue with linking dynamic libraries. I suspect that's not true either even if it might be technically possible to achieve it through some trickery (and why not risc-v, and other architectures too?).

khazit 11mo ago
Of course you still need one binary per CPU architecture. But when you rely on a dynamic link, you need to build from the same architecture as the target system. At that point cross-compiling stops being reliable.
- necovek 11mo ago
  I am complaining about the language (phrasing) used: a Python, TypeScript or Java program might be truly portable across architectures too. Since architectures are only brought up in relation to dynamic libraries, it implied it is otherwise as portable as above languages. With that out of the way, it seems like a small thing for the Go build system if it's already doing cross compilation (and thus has understanding of foreign architectures and executable formats). I am guessing it just hasn't been done and is not a big lift, so perhaps look into it yourself?
  - arccy 11mo ago
    they're only portable if you don't count the architecture specific runtime that you need to somehow obtain... go doesn't require dynamic linking for C, if you can figure out the right C compiler flags you can cross compile statically linked go+c binaries as well.
- swills 11mo ago
  I happily and reliably cross build Go code that uses CGO and generate static binaries on amd64 for arm64.
- vbezhenar 11mo ago
  Is it some tooling issue? Why is is an issue to cross-compile programs with dynamic linking?
  - dekhn 11mo ago
    In general, cross compilers can do dynamic linking.
    - spijdar 11mo ago
      In my experience, the cross-compiler will refuse to link against shared libraries that "don't exist", which they usually don't in a cross compiler setup (e.g. cross compiling an aarch64 application that uses SDL on a ppc64le host with ppc64le SDL libraries) The usual workaround, I think, is to use dlopen/dlsym from within the program. This is how the Nim language handles libraries in the general case: at compile time, C imports are converted into a block of dlopen/dl* calls, with compiler options for indicating some (or all) libraries should be passed to the linker instead, either for static or dynamic linking. Alternatively I think you could "trick" the linker with a stub library just containing the symbol names it wants, but never tried that.
      - dwattttt 11mo ago
        You just need a compiler & linker that understand the target + image format, and a sysroot for the target. I've cross compiled from Linux x86 clang/lld to macOS arm64, all it took was the target SDK & a couple of env vars. Clang knows C, lld knows macho, and the SDK knows the target libraries.
      - 1718627440 11mo ago
        Well, you need to link against them and you can't do that when they don't exist. I don't understand the purpose of a stub library, it is also only a file and if you need to provide that, you can also provide the real thing right away.
  - cxr 11mo ago
    It's a tooling issue. No one has done the work to make things work as smoothly as they could. Traditionally, cross-compilers generally didn't even work the way that the Zig and Go toolchains approach it—achieving cross-compilation could be expected to be a much more trying process. The Zig folks and the Go folks broke with tradition by choosing to architect their compilers more sensibly for the 21st century, but the effects of the older convention remains.
deleted 11mo ago
[deleted]
cxr 11mo ago
For a single binary that will actually run across both architectures, see <https://cosmo.zip/ https://cosmo.zip/>. Original discussion: <https://news.ycombinator.com/item?id=24256883 https://news.ycombinator.com/item?id=24256883>.

by necovek 11mo ago

khazit 11mo ago

Of course you still need one binary per CPU architecture. But when you rely on a dynamic link, you need to build from the same architecture as the target system. At that point cross-compiling stops being reliable.

necovek 11mo ago
I am complaining about the language (phrasing) used: a Python, TypeScript or Java program might be truly portable across architectures too. Since architectures are only brought up in relation to dynamic libraries, it implied it is otherwise as portable as above languages. With that out of the way, it seems like a small thing for the Go build system if it's already doing cross compilation (and thus has understanding of foreign architectures and executable formats). I am guessing it just hasn't been done and is not a big lift, so perhaps look into it yourself?
- arccy 11mo ago
  they're only portable if you don't count the architecture specific runtime that you need to somehow obtain... go doesn't require dynamic linking for C, if you can figure out the right C compiler flags you can cross compile statically linked go+c binaries as well.
swills 11mo ago
I happily and reliably cross build Go code that uses CGO and generate static binaries on amd64 for arm64.
vbezhenar 11mo ago
Is it some tooling issue? Why is is an issue to cross-compile programs with dynamic linking?
- dekhn 11mo ago
  In general, cross compilers can do dynamic linking.
  - spijdar 11mo ago
    In my experience, the cross-compiler will refuse to link against shared libraries that "don't exist", which they usually don't in a cross compiler setup (e.g. cross compiling an aarch64 application that uses SDL on a ppc64le host with ppc64le SDL libraries) The usual workaround, I think, is to use dlopen/dlsym from within the program. This is how the Nim language handles libraries in the general case: at compile time, C imports are converted into a block of dlopen/dl* calls, with compiler options for indicating some (or all) libraries should be passed to the linker instead, either for static or dynamic linking. Alternatively I think you could "trick" the linker with a stub library just containing the symbol names it wants, but never tried that.
    - dwattttt 11mo ago
      You just need a compiler & linker that understand the target + image format, and a sysroot for the target. I've cross compiled from Linux x86 clang/lld to macOS arm64, all it took was the target SDK & a couple of env vars. Clang knows C, lld knows macho, and the SDK knows the target libraries.
    - 1718627440 11mo ago
      Well, you need to link against them and you can't do that when they don't exist. I don't understand the purpose of a stub library, it is also only a file and if you need to provide that, you can also provide the real thing right away.
- cxr 11mo ago
  It's a tooling issue. No one has done the work to make things work as smoothly as they could. Traditionally, cross-compilers generally didn't even work the way that the Zig and Go toolchains approach it—achieving cross-compilation could be expected to be a much more trying process. The Zig folks and the Go folks broke with tradition by choosing to architect their compilers more sensibly for the 21st century, but the effects of the older convention remains.

deleted 11mo ago

[deleted]

cxr 11mo ago

For a single binary that will actually run across both architectures, see <https://cosmo.zip/ https://cosmo.zip/>. Original discussion: <https://news.ycombinator.com/item?id=24256883 https://news.ycombinator.com/item?id=24256883>.