* Tong Sun: > On Tue, Mar 19, 2019 at 12:00 PM Tong Sun wrote: >> >> On Tue, Mar 19, 2019 at 10:58 AM Florian Weimer wrote: >> > >> > * Tong Sun: >> > >> > > Aren't all go built binaries are statically-linked-binary? >> > > Then why I'm getting the following error? >> > >> > There are two different kinds of statically linked binaries: those >> > that link against glibc and those that do not. Static linking against >> > glibc should really be avoided, particularly with Go, which only needs >> > it for functionality that is *broken* in a statically linked glibc. >> > >> > Do you have a link to the binary in question? >> >> Thanks for your reply Florian. I'm still working on making the build >> work, but will get my package into shape and push an initial version >> for your to take a look... > > Hi Go team & Florian, > > I've upload the package "easygen" to > https://salsa.debian.org/go-team/packages/easygen > > It is still having the above statically-linked-binary problem. > > Somebody help me fix it please? This is a Go binary which does not link with glibc, only with the Go runtime. There is no technical problem with that, it's the preferred method of building such applications. It's not much different from building applications with any other language that lacks mature support for practical dynamic linking (which includes a stable compiler ABI and libraries with ABI stability).
The general issue with patching Go software applies, of course, but this is not really caused by static linking as such. I think the lintian check needs to be improved. There was already a bug about it: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911864> Apparently that doesn't work here for some reason. A better version of that stack would look for the presence of the GO buildid and the absence of telltale signs of glibc bits. For that to work, we could even add some markup to libc.a in glibc.
