Re: statically-linked-binary error
* 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.
Reply to: