[systemd-devel] build failures in latest master from d848b9cbfa0ba72381363accce481600169df2eb

[Colin Walters]

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.
See:
https://mail.gnome.org/archives/performance-list/2006-April/msg00042.html
(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.