It seems like dmraid link line needs to include -lselinux for the static link because libdevmapper.a won't have the symbols from libselinux.a although they refer to them. dynamic link would just work fine, but will require libdevmapper libs to be present in initrd. -------------------------------------------------------------------- gcc -o dmraid dmraid.o commands.o toollib.o -L/var/tmp/genkernel/9008.19588.27156.8193/device-mapper/lib -static -L../lib \ -L/lib -ldmraid -lz -ldevmapper /var/tmp/genkernel/9008.19588.27156.8193/device-mapper/lib/libdevmapper.a(libdm-common.o): In function `dm_set_selinux_context': libdm-common.c:(.text+0x4da): undefined reference to `is_selinux_enabled' libdm-common.c:(.text+0x4f3): undefined reference to `matchpathcon' libdm-common.c:(.text+0x533): undefined reference to `lsetfilecon' libdm-common.c:(.text+0x541): undefined reference to `freecon' libdm-common.c:(.text+0x59c): undefined reference to `freecon' collect2: ld returned 1 exit status make[1]: *** [dmraid] Error 1 make[1]: Leaving directory `/var/tmp/genkernel/9008.19588.27156.8193/dmraid/1.0.0.rc13/tools' make: *** [tools] Error 2 * Gentoo Linux Genkernel; Version 3.4.5^[[0m * Running with options: --gensplash=emergence --dmraid --gensplash-res=1280x1024 --no-initrdmodules initrd * ERROR: Failed to compile the "" target... * -- Grepping log... -- * -- End log... -- * Please consult /var/log/genkernel.log for more information and any * errors that were reported above. * Report any genkernel bugs to bugs.gentoo.org and * assign your bug to genkernel@gentoo.org. Please include * as much information as you can in your bug report; attaching -----------------------------------------------------------------------
this change fixes it. # cd /usr/share/genkernel # diff -u gen_compile.sh.orig gen_compile.sh --- gen_compile.sh.orig 2006-12-08 13:53:07.000000000 -0800 +++ gen_compile.sh 2006-12-08 13:55:55.000000000 -0800 @@ -511,7 +511,8 @@ gen_die 'Configure of dmraid failed!' #We dont necessarily have selinux installed yet .. look into selinux global support in the future. - sed -i tools/Makefile -e "s|DMRAIDLIBS += -lselinux||g" + # sed -i tools/Makefile -e "s|DMRAIDLIBS += -lselinux||g" + echo "DMRAIDLIBS += -lselinux -lsepol" >> tools/Makefile mkdir -p "${TEMP}/dmraid" print_info 1 'dmraid: >> Compiling...' compile_generic '' utils
Created attachment 103647 [details, diff] as a unified patch the diff's formatting got screwed, sorry.
Thanks... I've fixed this in subversion and it should be good to go in genkernel 3.4.6...
After, I posted the patch, I realized that this will force libselinux and libsepol on users without the ebuild specifically requiring it. So, the right solution for the problem at hand is: use the selinux USE flag, put a dep in genkernel ebuild for libselinux and pass --disable-selinux explicitly to device-mapper configure in gen_compile.sh if selinux is not in USE. device-mapper devs decided that they will enable selinux by default and users have to disable it explicitly if they don't want it, and this is what lead to the undefined variables. So, this approach will resolve the undefined symbols (this bug) as well as keep the deps sane. We need to modify the patch I posted earlier and make it link to selinux and sepol only if selinux is in use. wolf, is it possible for you to handle this or do I need to put a patch out? sorry for any confusion I might have caused.
If you can come up with a patch, that would be great. Otherwise, I'll try to get it into the next genkernel release.
Created attachment 104001 [details, diff] patch for /usr/share/genkernel/gen_compile.sh This takes hasq() and use() code from ebuild.sh shamelessly and uses 'emerge --info' to get USE variable required to for use() function.
Created attachment 104002 [details, diff] The patch for the ebuild itself It simply puts selinux in IUSE and puts a depend on libselinux for USE flag selinux.
wolf, let me know if any of this looks good to you. I have tested it here on amd64 and it works with and without libselinux and libsepol. ebuild is patched for 3.4.5-r1 in portage tree currently.
We can't rely on anything "portage-specific" within genkernel itself. This is due to the design of genkernel, which allows it to be used on any distribution. The likely best solution is to check for USE=selinux and modify the sources for genkernel at install time, rather than checking "emerge --info" at runtime. It looks like it is simple enough, so I'll probably get to it today using the information in your patches. Thanks for the help. =]
would you please put out a test patch here? thanks. PS: I always thought genkernel was a gentoo thing...thanks for correcting on that front!
OK... now I've made the gen_compile.sh default to working without selinux, since that's the Gentoo "default"... when I update the ebuild, USE=selinux will uncomment the two places required for selinux support.
Created attachment 104050 [details, diff] genkernel.patch This patch is what I've committed... of course, if you're testing it, you'll need to manually remove the 2 "###" in front of the selinux stuff. Basically, I'm going to have the following in the ebuild: use selinux && dosed -i 's/###//' gen_compile.sh
+ ###mymapperconf="--disable-selinux ${mymapperconf}" in the patch will become: mymapperconf="--disable-selinux ${mymapperconf}" if selinux is in the USE. We want the opposite. I think it was desired that we explicitly disable selinux for the default setup because that's how device-mapper devs want it i.e. enable selinux by default (there is collision between gentoo default and device-mapper default). In nutshell, with your patch, we will still see the undefined variables. I think maybe something like this in the ebuild might work: use selinux && sed -e "s/--disable-selinux//g" .... and have the --disable-selinux in mymapperconf by default with the patch.
Bleh... you're right... for some reason I was thinking the "--disable-selinux" was for enabling it. Anyway, I've got it adjusted now in SVN.
Fixed in 3.4.6
This now happens on amd64 during the lvm build; adding --disable-selinux to the configure line in gen_compile.sh allows it to build correctly.
Could you file a new bug for that, since it's a different (though related) issue and doesn't belong on this resolved bug?
