Hi! I noticed the 3.5.3.3 version of genkernel became stable. However, it forces to use the util-linux package built with static libraries instead of shared or dynamic ones (I mean the USE="static-libs" enabled) and I don't know why. I asked about the possible risks in the forums (see https://forums.gentoo.org/viewtopic-t-1082662.html), so... is there a way to optionally use either shared or static libraries for genkernel) Or may I move to genkernel-next? I think using static-libs may not be a good idea. Anyways, thanks.
Please do not make static libs a requirement. Thank you!
Genkernel team, is it possible to put this requirement behind a USE flag for the particular genkernel initramfs feature which requires util-linux?
(In reply to jorgicio from comment #0) > I noticed the 3.5.3.3 version of genkernel became stable. However, it forces > to use the util-linux package built with static libraries instead of shared > or dynamic ones (I mean the USE="static-libs" enabled) and I don't know why. util-linux[static-libs] causes it to build the static libraries in ADDITION to the dynamic libraries. The util-linux binaries are linked against the dynamic libraries. If they aren't please open a new bug against util-linux showing the ldd output on the util-linux binaries in question. I CANNOT reproduce your util-linux claim with sys-apps/util-linux-2.32-r3. > I asked about the possible risks in the forums (see > https://forums.gentoo.org/viewtopic-t-1082662.html), so... is there a way to > optionally use either shared or static libraries for genkernel) Or may I > move to genkernel-next? I think using static-libs may not be a good idea. The features that use it, off the top of my head - lvm - dmraid - fuse - unionfs_fuse - iscsi Size impact, when I last did this, showed that using dynamic libraries in this case bloated the initramfs, as static-libs allowed the linker to just link in the used functions. Smarter tooling in future might consider removing functions from the dynamic library instead, if nothing in the initramfs environment is using said functions. Future plans as I have stated for genkernel is for genkernel to STOP generating the initramfs entirely, and offload that responsibility to another package (dracut, better-initramfs, really anything that is configurable enough to cover the functionality presently in the genkernel initramfs). That leaves genkernel responsible for building the kernel and calling that other tool to get an initramfs built (with modules from the kernel build, or putting the initramfs inside the kernel as applicable).
(In reply to Robin Johnson from comment #3) > (In reply to jorgicio from comment #0) > > I noticed the 3.5.3.3 version of genkernel became stable. However, it forces > > to use the util-linux package built with static libraries instead of shared > > or dynamic ones (I mean the USE="static-libs" enabled) and I don't know why. > util-linux[static-libs] causes it to build the static libraries in ADDITION > to the dynamic libraries. The util-linux binaries are linked against the > dynamic libraries. If they aren't please open a new bug against util-linux > showing the ldd output on the util-linux binaries in question. > > I CANNOT reproduce your util-linux claim with sys-apps/util-linux-2.32-r3. > > > > I asked about the possible risks in the forums (see > > https://forums.gentoo.org/viewtopic-t-1082662.html), so... is there a way to > > optionally use either shared or static libraries for genkernel) Or may I > > move to genkernel-next? I think using static-libs may not be a good idea. > > The features that use it, off the top of my head > - lvm > - dmraid > - fuse > - unionfs_fuse > - iscsi > > Size impact, when I last did this, showed that using dynamic libraries in > this case bloated the initramfs, as static-libs allowed the linker to just > link in the used functions. Smarter tooling in future might consider > removing functions from the dynamic library instead, if nothing in the > initramfs environment is using said functions. > > Future plans as I have stated for genkernel is for genkernel to STOP > generating the initramfs entirely, and offload that responsibility to > another package (dracut, better-initramfs, really anything that is > configurable enough to cover the functionality presently in the genkernel > initramfs). That leaves genkernel responsible for building the kernel and > calling that other tool to get an initramfs built (with modules from the > kernel build, or putting the initramfs inside the kernel as applicable). The topic here is not about initramfs (I know I can relegate the use for another package like dracut), but I think static-libs may be not mandatory. Also, I'm using the stable version of util-linux, 2.30.2-r1, and it asks to be built with static-libs. I think anyone should use it if wanted only.
(In reply to jorgicio from comment #4) > (In reply to Robin Johnson from comment #3) > > The topic here is not about initramfs (I know I can relegate the use for > another package like dracut), but I think static-libs may be not mandatory. > Also, I'm using the stable version of util-linux, 2.30.2-r1, and it asks to > be built with static-libs. I think anyone should use it if wanted only. yes why now genkernel needs util-linux build with static-libs?
Closing this bug as invalid: 1) USE=static-libs doesn't add any additional requirement (i.e. USE=static-libs doesn't pull in additional libraries or requires additional static libs) 2) Difference between sys-apps/util-linux[-static-libs] and sys-apps/util-linux[static-libs]: > --- /without-static-libs.files 2019-03-22 16:05:11.964996964 +0100 > +++ /with-static-libs.files 2019-03-22 16:04:25.475997214 +0100 > @@ -127,10 +127,15 @@ > /usr/include/uuid > /usr/include/uuid/uuid.h > /usr/lib64 > +/usr/lib64/libblkid.a > /usr/lib64/libblkid.so > +/usr/lib64/libfdisk.a > /usr/lib64/libfdisk.so > +/usr/lib64/libmount.a > /usr/lib64/libmount.so > +/usr/lib64/libsmartcols.a > /usr/lib64/libsmartcols.so > +/usr/lib64/libuuid.a > /usr/lib64/libuuid.so > /usr/lib64/pkgconfig > /usr/lib64/pkgconfig/blkid.pc 3) Without USE=static-libs, LVM will fail to build: > *-- > *gcc -fPIC -L. -L/var/tmp/genkernel/29490.29538.12030.44889/libaio/lib -L../../libdm -L../../lib -L../../libdaemon/client -L../../daemons/dmeventd -Wl,--export-dynamic dmeventd.o \ > * -o dmeventd -ldl -ldevmapper-event -ldevmapper -lpthread > *gcc -fPIC -L/var/tmp/genkernel/29490.29538.12030.44889/libaio/lib -L../../libdm -L../../lib -L../../libdaemon/client -L../../daemons/dmeventd -Wl,--no-export-dynamic -static -L. -L../../libdm/ioctl dmeventd.o \ > * -o dmeventd.static -ldl -ldevmapper-event -ldevmapper -lpthread -lblkid -luuid -lm > */usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: dmeventd.o: in function `_load_dso': > *dmeventd.c:(.text+0x4fd): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > */usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lblkid > */usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -luuid > *collect2: error: ld returned 1 exit status > *make[2]: *** [Makefile:68: dmeventd.static] Error 1 > *make[2]: Leaving directory '/var/tmp/genkernel/29490.29538.12030.44889/LVM2.2.02.183/daemons/dmeventd' > *make[1]: *** [../make.tmpl:360: dmeventd.device-mapper] Error 2 > *make[1]: Leaving directory '/var/tmp/genkernel/29490.29538.12030.44889/LVM2.2.02.183/daemons' > *make: *** [make.tmpl:360: daemons.device-mapper] Error 2 > *make: *** Waiting for unfinished jobs.... > * [CC] dmsetup > * [CC] dmsetup.static > */usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lblkid > */usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -luuid > *collect2: error: ld returned 1 exit status > *make[1]: *** [Makefile:137: dmsetup.static] Error 1 > *make[1]: *** Waiting for unfinished jobs.... > *make[1]: Leaving directory '/var/tmp/genkernel/29490.29538.12030.44889/LVM2.2.02.183/tools' > *make: *** [make.tmpl:360: tools.device-mapper] Error 2 > *--
