Hi, On Tue, Nov 1, 2011 at 4:39 PM, Lennart Poettering <lenn...@poettering.net> wrote: > Hmm, let me see if I get this right: with this patch applied we'd build > cap and selinux support into libsystemd-basic.la, but we wouldn't link > against the respective libraries but instead do that in the binaries > which pull in the .la? > > I am not sure I like this. I mean, I understand the goal, and it's a > good one, but I think if we do this we should do this properly, and > split up util.c so that the stuff that uses caps and selinux is > independent of the rest and can be pulled in individually as needed.
This is true for the libcap case - libcap is only used by util.c so is easy to split out. But with selinux included, the task is more complicated. For example, label.c (part of libsystemd-basic) also uses libselinux, so we need to move it out somewhere else (lets say we put it in a new library: libsystemd-extra). But the label_ functions are used several places inside util.c itself. Things are tangled. If I were to go down this path further I think we'd end up moving a huge amount of stuff to libsystemd-extra. Instead, do any of the following options make sense? - Special-case systemd-timestamp because it's used in the initramfs. Instead of linking against libselinux-basic just pull in util.c directly into the compilation and link with -lrt. - Create a new shared library used in compilation (libsystemd-verybasic?), initially only containing the time-related functions used by systemd-timestamp. Link systemd-timestamp against that, and be happy. - While linking executables (or immediately after), perform some checks to see if the linked libraries are *really* necessary, and if they aren't, drop the links. vim does this via the attached script. Thanks, Daniel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
