Go is portable, until it isn't
simpleobservability.com
Go is portable, until it isn't
1–10 of 138 posts
Re: Go is portable, until it isn't
#2This 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?).
Re: Go is portable, until it isn't
#3This 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?).
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.
Re: Go is portable, until it isn't
#4This is an (organizational) tooling problem, not a language problem - and is no less complicated when musl libc enters the discussion.
Re: Go is portable, until it isn't
#5This is an (organizational) tooling problem, not a language problem - and is no less complicated when musl libc enters the discussion.
The conclusion of the article says that it's not the language problem either. Under the title "So, is Go the problem?" Or do you mean something else here?
Re: Go is portable, until it isn't
#6This 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?).
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.
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?
Re: Go is portable, until it isn't
#7Once you use CGO, portability is gone. Your binary is no longer staticly compiled.
This can happen subtley without you knowing it. If you use a function in the standard library that happens to call into a CGO function, you are no longer static.
This happens with things like os.UserHomeDir or some networking things like DNS lookups.
You can "force" go to do static compiling by disabling CGO, but that means you can't use _any_ CGO. Which may not work if you require it for certain things like sqlite.
Re: Go is portable, until it isn't
#8Earlier quoted context omitted.
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.
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 o…
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.
Re: Go is portable, until it isn't
#9I ran into this issue when porting term.everything[0] from typescript to go. I had some c library dependencies that I did need to link, so I had to use cgo.
My solution was to do the build process on alpine linux[1] and use static linking[2]. This way it statically links musl libc, which is much friendlier with static linking than glibc.
Now, I have a static binary that runs in alpine, Debian, and even bare containers.
Since I have made the change, I have not had anyone open any issues saying they had problems running it on their machines. (Unlike when I was using AppImages, which caused much more trouble than I expected)
[0] https://github.com/mmulet/term.everything look at distribute.sh and the makefile to see how I did it.
[1]in a podman or docker container
[2] -ldflags '-extldflags "-static"'
Re: Go is portable, until it isn't
#10Once you use CGO, portability is gone. Your binary is no longer staticly compiled. This can happen subtley without you knowing it. If you use a function in the standard library that happens to call into a CGO function, you are no longer static. This happens with things like os.UserHomeDir or some networking things like DNS lookups. You can "force" go to do static compiling by disabling CGO, but that means you can't u…
You can definitely use CGO and still build statically, but you do need to set ldflags to include -static.