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

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



Hi,

Am 14.01.23 um 15:15 schrieb Shengjing Zhu:
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.

I am not entirely sure, but I believe I tried to package Caddy with small as possible differences to upstream, who distribute a standalone executable (with good reasons though, which admittedly do not apply for a distro package)

With CGO enabled, the whole thing is solved. thanks a lot for hint!


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

Agreed :)

Peymaneh

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: