[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lintian error: shared-library-lacks-prerequisites



On Sat, Jan 14, 2023 at 9:48 PM Peymaneh <peymaneh@posteo.net> wrote:
>
> Hi,
>
> I have a question regarding the static linking of Go programs:
>
> I added -buildmode=pie to the compiler flags for Caddy[1] for additional
> hardening. lintian now complains:
>
> > caddy: shared-library-lacks-prerequisites [usr/bin/caddy]
> > The listed shared library doesn't include information about the other libraries against which it was linked.
> >
> > More specifically, "ldd foo.so" should report such other libraries. In your case, it reports "statically linked".
> >
> > The fix is to specify the libraries. One way to do so is to add something like "-lc" to the command-line options for "ld".
>
> I am not sure what to think of this:
>
> First, Caddy is not a shared library even and, as any other Go
> executables, is usually statically linked.
>
> For amd64 the Go compiler uses internal linking and
>
> % objdump -p $caddy-binary-armhf | grep NEEDED
> %
>
> is empty, but this is just as is should be.
>
> For some other platforms -buildmode=pie requires building with an
> external linker, and the Caddy binary built for those correctly includes
> this information:
>
> % objdump -p $caddy-binary-armhf | grep NEEDED
>    NEEDED               libc.so.6
>
> it seems to me this lintian warning is incorrect. Would it be sensible
> to overwrite it?

I am inclined to lintian this time.

The binary is rather odd. It's statically linked, but the interpreter
is set as well.
The result comes from CGO_ENABLED=0 and -buildmode=pie. I'm not sure
if these options are sensible to use together.

But why do you want CGO_ENABLED=0? We should avoid this in Debian
packaging. Shared binary is much preferred for distribution packages.

Generally speaking, I prefer not hacking build flags in individual
packages. This is the job of dh-golang.

--
Shengjing Zhu


Reply to: