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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
