On Mon, 03.06.13 00:52, Stephan Raue (mailingli...@openelec.tv) wrote: > > Am 02.06.2013 19:36, schrieb Greg KH: > >On Sun, Jun 02, 2013 at 07:28:57PM +0200, Stephan Raue wrote: > > > >>i dont agree, i some cases it makes sense. since udev is included in > >>systemd and udev has now its own buildins for the modprobe stuff it > >>should be possible to use kmod statically linked, esp. if no other > >>installed program uses kmod (and for our usage the kmod userspace > >>binarys are not neccessary) > > > >If you are so worried about other programs / users calling kmod, then > >just build your needed kernel modules into the kernel and don't use any > >kernel modules at all. > > > i am not much worried about this, but more about the comment "Do not > use static linking, with systemd, ever, in fact do not use with any > other component.". Statically linking works for so many programs and > even kmod supports the "--enable-static" configure option. So > basically i tried to report this broken behavior, because i never > seen a statement like "dont link anything statically against > systemd"
Static linking is broken for many reasons. One reason is the namespace issue you ran into. If you want to make static linking work for you, then I recommend working on binutils to fix the namespacing issues (i.e. introduce private visibility to static libraries, good luck). To make this very clear: we will continue to use *private* symbols in systemd that are not namespaced. We will not rename these symbols just because some other library has similarly named *private* symbols. Staticially linking means creating a universal namespace for symbols, and that's just impossible and broken... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
