On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote: > So I am pretty sure libsystemd-id128, libsystemd-login, > libsystemd-journal should just end up in a single libsystemd.so together > with the event loop, the bus, the asyncns stuff and more. All this > functinality requires each other, and should nto pull in its own copy of > src/shared/*.c each time. I now pushed a series of patches which merge libsystemd-id128 and libsystemd-login into libsystemd. I also changed the linker to gold by default, becuase bfd had a bug [1]. It has since been fixed, but not released yet, and anyway gold is minimally faster. When running distcheck, which uses -flto, a bug [2] in gold was uncovered. I worked around it by disabling lto for the compat libsystemd-login. I doesn't matter much anyway for this lib. All in all, this doesn't give a good feeling... I wouldn't be surprised if other issues pop up. I guess it's better to do this now and potentially revert than right before release.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16467 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=16504 libsystemd-journal is more complicated. It uses libsystemd-label, which in turn uses libselinux. Doing a straighforward merge would mean that everything is linked with libselinux. I think that the idea of splitting the reporting side of sd-journal and moving it to libsystemd, while keeping the rest separate, might be a good idea. Comments? Zbyszek > There are some exceptions to this though. For example, I am unsure about > libsystemd-daemon: it's relatively easy to maintain this in its own lib, > sicne so far it actually doesn't use any of the shared code, because > its' embeddable. But then agaiun, given that this library evolves too, > and given that distros generally don't like embedding anyway, we should > probably just merge it into libsystemd.so too, in particular since the > functions it provides are really low-level stuff. libsystemd-dhcp > however really sounds like something that will always be consumer of > services, never > provider of services from this new libsystemd.so, and the set of > programs making use of it will always be very small, so we can and > should certainly keep it a seperate lib. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
