[systemd-devel] build failures in latest master from d848b9cbfa0ba72381363accce481600169df2eb
walters at verbum.org
Tue Feb 5 04:01:50 PST 2013
On Tue, 2013-02-05 at 06:40 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 31, 2013 at 07:21:27PM -0500, Colin Walters wrote:
> > Using -Wl,--gc-sections helps a lot, but still. We could just put it in
> > a private path like /usr/lib/systemd/libsystemd-shared.so.
> I have been wanting to do something like that for a long while.
> I thought it would be much more complicated though, so I left it for later :)
Yeah, this is a case where libtool abstracting over the difference
between static and dynamic libraries is useful.
The only non-obvious thing was having to override the global
-fvisibility=hidden with -fvisibility=default. The other option to that
would be annotating all of shared.so with _public_ but that's kind of
unnecessarily painful since it's not really public ABI.
> > [a few minutes pass] Something like the attached patch. But doing it
> > against master I'm still running into apparent build race conditions
> > where 'make' works, but 'make -j 8' falls over.
> Hm, maybe some build-over automatic dependency? I tried a few different
> build parallelization settings and it seems to work fine. Looking at the
> rules, it should too.
True - I wasn't doing clean (git clean -dfx; ./autogen.sh) builds each
time, but starting from a tree with --enable-dependency-tracking on (as
it is by default).
> $ du /var/tmp/inst? -cs
> 28084 /var/tmp/inst
> 16760 /var/tmp/inst-shared
> Biggest changes:
> /usr/lib: 19448 -> 11868
> /usr/bin: 5968 -> 2224
> So this seems like a big win.
That's more than i expected - about 40%! I bet a lot of that bloat
though is duplicated debuginfo, not actual text or data. In other words
if you're on a system with split debuginfo (as everyone should be), it's
still a win, just not as much.
> What are the downsides?
IIRC at runtime each .so requires minimally a writable page per process.
(It's worth reading the whole thread too)
But with static libraries, you have the code actually duplicated at in
both memory (* N processes) and disk (* N binaries).
> (One I see immediately: libudev links against libsystemd-shared,
> people who only compile udev might not like that.)
Oh, true. Honestly we should really add --enable-udev-only or
something. I know Lennart has been against a huge explosion in build
flags given you can just pick what you want out of make install
DESTDIR=, but this one seems worth explicitly specifying. In that case
we could add an AM_CONDITIONAL to build libsystemd-shared static again.
More information about the systemd-devel