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

[Kay Sievers]

On Tue, Feb 5, 2013 at 1:01 PM, Colin Walters <walters at verbum.org> wrote:
> 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).

We do not want to place shared libraries with private APIs in the
system. Other people might rely on stuff which we can never track.
Considering the "creativity" of people working in our area, we just
cannot do that.

>> (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.

No, we don't want to make any promises about a separate udev *build*,
we only ensure that it *runs* properly. There is no question that we
will keep the *running* part alive as long as needed, but we will not
optimize any building. Such complexity in the buildsys to optimize
specific targets, needlessly complicate things for us, explode the
matrix of options, and we should avoid them for a lot of reasons. They
will just get into our way in the future.

Kay