Your message dated Mon, 20 Jul 2020 23:39:08 +0200
with message-id <1538baa0-8fc8-c647-d15d-ab3bc4d84...@debian.org>
and subject line Re: libsystemd-dev: static library not provided
has caused the Debian Bug report #915566,
regarding libsystemd-dev: static library not provided
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
915566: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915566
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libsystemd-dev
Version: 239-14
Severity: wishlist
libsystemd-dev doesn't provide a static library. Is this deliberate?
Support for a static libsystemd and libudev seems to have been added to
the upstream Meson build system in v239.
I discovered this while expanding debian/tests/build in dbus to
exercise static linking, which didn't work. The test could in principle
be made to use a static libdbus and a dynamic libsystemd, but that's
rather more complicated than the semi-obvious use of pkg-config,
gcc -static -o static connect.c $(pkg-config --cflags --libs --static
dbus-1)
which is what I was trying to test.
If you don't consider a shared libsystemd to be useful, please close this
bug or mark it as wontfix. (However, if lower-level libraries are
unilaterally built as shared-only, this significantly reduces the usefulness
of building static higher-level libraries.)
smcv
--- End Message ---
--- Begin Message ---
On Tue, 3 Sep 2019 13:00:31 +0100 Simon McVittie <s...@debian.org> wrote:
> On Sat, 31 Aug 2019 at 00:31:12 +0200, Michael Biebl wrote:
> > Simon, have you tried building systemd with -Dstatic-libsystemd=true
> > -Dstatic-libudev=true ? Does this produce something useful?
>
> I haven't tried it.
>
> > Upstream doesn't seem to be too keen on supporting static builds, so if
> > we divert here downstream, I'd be interested if there is actual demand
> > from users of such a libsystemd.a or if this all mostly hyphothetical.
>
> This is hypothetical, and if you want to say "no" and mark this as wontfix
> or close it, that's fine; but I wanted to ask the question rather than
> making an assumption about the likely answer.
>
> The context is that I have been trying to write autopkgtests for -dev
> packages, on the basis that if we have a feature, we should prove that
> it works; and I've found that when a library in the dependency stack is
> shared-only (for example libdbus depends on libsystemd), it is not at
> all obvious how to link statically to the depending library (libdbus).
> The obvious rune
>
> cc -Wl,--no-as-needed -static -otest test.c `pkg-config --static --cflags
> --libs dbus-1`
>
> fails, because there is no libsystemd.a to link.
>
> (I'm using -Wl,--no-as-needed because the test.c that I'm currently
> playing with doesn't actually call into libdbus, and I don't want to
> invalidate the test results by having the linker decide not to link
> libdbus or libsystemd after all; in real autopkgtests I try to call at
> least a harmless function like dbus_get_version().)
>
> It is still possible to link libsystemd and libc dynamically, but libdbus
> statically, with something like
>
> cc -Wl,--no-as-needed -otest test.c `pkg-config --static --cflags --libs
> dbus-1 | perl -pe 's,(^|\s)-ldbus-1(\s|$),
> /usr/lib/x86_64-linux-gnu/libdbus-1\.a ,'`
>
> but that requires you to know the physical location of the library, and
> once you have to rely on *anything* with shared linkage, you might as
> well bundle *everything* with shared linkage (and -Wl,-rpath,'$ORIGIN'
> or similar), at which point you've gained nothing from static libraries.
>
> That would point towards a conclusion that if a library like libdbus
> has shared-only dependencies like libsystemd, then libdbus should also
> become shared-only, which would reduce the size of the binary archive
> and the time taken to compile, but would harm the possibly-hypothetical
> use cases that are the reason Policy tells us to build static libraries?
>
> Another possible direction would be to disable static libraries in
> general, except in cases where a bug report indicates that a real user
> genuinely wants them (and has a recipe for testing that they work).
I typically handled it like this. If there wasn't a demand for it, I
didn't bother with pro-actively enabling static libraries.
Let's do the same here. Unless we have users reporting a demand for
having such static libraries (with a reasonable use case), we just keep
the staus-quo.
Regards,
Michael
signature.asc
Description: OpenPGP digital signature
--- End Message ---
