After update from kmod-13-r1 to kmod-15: -87976 /bin/kmod -949827ebb1500da63b91d1a4fc1093a9 /bin/kmod +157664 /bin/kmod +0e5dd8e8ea8cdbcf9acf58b4c002fc8a /bin/kmod /bin/kmod: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.39, stripped libc.so.6 -libkmod.so.2 From /usr/share/doc/kmod-15/NEWS.bz2: kmod 15 ======= ... - New features: ... - kmod binary statically links to libkmod - if distro is only interested in the kmod tool (for example in an initrd) it can refrain from installing the library dracut and genkernel-next add udevd to initramfs.img, so we have libkmod in it anyway. Linking to libkmod statically is useless and only increases size of initramfs and backups.
This seems like an issue which should be discussed/addressed upstream. Otherwise, we will end up forking the build system, which sounds like a PITA.
oh, the irony. it hurts so bad.
should be all set now in the tree; thanks for the report! Commit message: Do not statically link libkmod http://sources.gentoo.org/sys-apps/kmod/files/kmod-15-dynamic-kmod.patch?rev=1.1 http://sources.gentoo.org/sys-apps/kmod/kmod-15-r1.ebuild?rev=1.1
(In reply to SpanKY from comment #3) > should be all set now in the tree; thanks for the report! the patch is broken re: bug 494806
and upstream rejected the patch too as incomplete: http://thread.gmane.org/gmane.linux.kernel.modules/1206
Created attachment 394188 [details, diff] kmod ebuild using autotools-utils and more
Created attachment 394190 [details, diff] kmod patch that handle internal copy of libkmod issue