| |
| ▲ | necovek 9 days ago | parent | next [-] | | 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 4 days ago | parent [-] | | 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. |
| |
| ▲ | vbezhenar 4 days ago | parent | prev | next [-] | | Is it some tooling issue? Why is is an issue to cross-compile programs with dynamic linking? | | |
| ▲ | cxr 4 days ago | parent | next [-] | | 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. | |
| ▲ | dekhn 4 days ago | parent | prev [-] | | In general, cross compilers can do dynamic linking. | | |
| ▲ | spijdar 4 days ago | parent [-] | | 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 4 days ago | parent | next [-] | | 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 2 days ago | parent | prev [-] | | 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. |
|
|
| |
| ▲ | swills 4 days ago | parent | prev [-] | | I happily and reliably cross build Go code that uses CGO and generate static binaries on amd64 for arm64. |
|
