Re:The Simplicity of Single-File Golang Deployments
by dilyevsky on Wednesday March 22, 2023 @05:07PM
(#35267095)
> CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static'
Unless you cant use musl for some reason, but that’s a glibc problem, not Go
Re:The Simplicity of Single-File Golang Deployments
by aatd86 on Wednesday March 22, 2023 @06:34PM
(#35267962)
Some people are writing alternative via WebAssembly.
For instance wazero which I'm really excited about.
https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...
Re:The Simplicity of Single-File Golang Deployments
by cookiengineer on Thursday March 23, 2023 @12:48AM
(#35270656)
In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen.
And there's also "purego" as an implementation that directly generates shellcode.
Maybe those will help you, too?
I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.
I run a few Go apps, all are single executables, upgrading to new releases has never been easier.
if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.