| Summary: | gcc fails to pull in emul-linux-x86-xlibs in selinux amd64 profiles which use.mask multilib | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andy Getz <suertreus> |
| Component: | Hardened | Assignee: | SE Linux Bugs <selinux> |
| Status: | VERIFIED FIXED | ||
| Severity: | minor | CC: | gizmo, pebenito |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 365483 | ||
| Attachments: |
durandal@tomp ~ $ emerge --info
/mnt/build/portage/sys-devel/gcc-4.5.1-r1/work/build/x86_64-pc-linux-gnu/32/libjava/config.log /mnt/build/portage/sys-devel/gcc-4.5.1-r1/temp/build.log |
||
Created attachment 255225 [details]
durandal@tomp ~ $ emerge --info
Created attachment 255227 [details]
/mnt/build/portage/sys-devel/gcc-4.5.1-r1/work/build/x86_64-pc-linux-gnu/32/libjava/config.log
Created attachment 255231 [details]
/mnt/build/portage/sys-devel/gcc-4.5.1-r1/temp/build.log
Redacted for sanity/filesize.
There is indeed something weird with (no)multilib and the SELinux profiles. A suggestion is made to clean up the profiles a bit by using a features/selinux dependency within the profile rather than a new profile tree See also http://thread.gmane.org/gmane.linux.gentoo.hardened/4820 This is now fixed with the new profiles. |
Part of GCC fails to configure with USE="gcj -multilib": tomp ~ # emerge -1a "=sys-devel/gcc-4.5.1-r1" ... [ebuild NS ] sys-devel/gcc-4.5.1-r1 [4.4.5] USE="doc fortran gcj graphite gtk hardened mudflap nls nptl openmp (-altivec) -bootstrap -build (-fixed-point) (-libffi) -lto (-multilib) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB ... checking for XTestQueryExtension in -lXtst... no configure: error: libXtst not found, required by java.awt.Robot make[1]: *** [configure-target-libjava] Error 1 make[1]: Leaving directory `/mnt/build/portage/sys-devel/gcc-4.5.1-r1/work/build' make: *** [bootstrap-lean] Error 2 emake failed * ERROR: sys-devel/gcc-4.5.1-r1 failed: * emake failed with bootstrap-lean ... Why am I missing the appropriate libXtst.so? From another machine in a non-selinux amd64 multilib profile that has GCC built successfully with USE="gcj": durandal@tycho ~ $ equery b `locate libXtst.so` * Searching for /usr/lib32/libXtst.so,/usr/lib32/libXtst.so.6,/usr/lib32/libXtst.so.6.1.0,/usr/lib64/libXtst.so,/usr/lib64/libXtst.so.6,/usr/lib64/libXtst.so.6.1.0 ... app-emulation/emul-linux-x86-xlibs-20100915 (/usr/lib32/libXtst.so.6.1.0) app-emulation/emul-linux-x86-xlibs-20100915 (/usr/lib32/libXtst.so.6 -> libXtst.so.6.1.0) app-emulation/emul-linux-x86-xlibs-20100915 (/usr/lib32/libXtst.so -> libXtst.so.6.1.0) x11-libs/libXtst-1.2.0 (/usr/lib64/libXtst.so.6.1.0) x11-libs/libXtst-1.2.0 (/usr/lib64/libXtst.so -> libXtst.so.6.1.0) x11-libs/libXtst-1.2.0 (/usr/lib64/libXtst.so.6 -> libXtst.so.6.1.0) Why wasn't the providing package (app-emulation/emul-linux-x86-xlibs) pulled in by DEPEND? durandal@tomp ~ $ grep "^DEPEND" /usr/portage/gentoo/sys-devel/gcc/gcc-4.5.1-r1.ebuild -A8 DEPEND="${RDEPEND} test? ( >=dev-util/dejagnu-1.4.4 >=sys-devel/autogen-5.5.4 ) >=sys-apps/texinfo-4.8 >=sys-devel/bison-1.875 elibc_glibc? ( >=sys-libs/glibc-2.8 ) amd64? ( multilib? ( gcj? ( app-emulation/emul-linux-x86-xlibs ) ) ) ppc? ( >=${CATEGORY}/binutils-2.17 ) ppc64? ( >=${CATEGORY}/binutils-2.17 ) >=${CATEGORY}/binutils-2.15.94" Where is multilib use.masked? durandal@tomp ~ $ ls -la /etc/make.profile lrwxrwxrwx. 1 root root 65 Nov 17 00:21 /etc/make.profile -> ../usr/portage/gentoo/profiles/selinux/v2refpolicy/amd64/hardened durandal@tomp ~ $ find /usr/portage/gentoo/profiles/selinux -name use.mask | xargs grep multilib -B1 /usr/portage/gentoo/profiles/selinux/use.mask-# Only used by mips and old amd64 profiles /usr/portage/gentoo/profiles/selinux/use.mask:multilib The obvious workaround is to emerge -1 app-emulation/emul-linux-x86-xlibs, but I think this is a real (though low-impact) bug. It will probably only hit systems that are being newly-installed with this profile and these useflags; any in-use desktop box will probably have long since pulled in the missing dep as mine above (tycho) must have. I assume multilib is use.masked by selinux for some good reason I am not aware of and thus the obvious solution of un-use.masking that flag is inappropriate or inadvisable. One alternative that occurs to me is to have the gcc ebuilds pull in emul-linux-x86-xlibs in the case of USE="amd64 selinux gcj", but that's a little icky too. `emerge --info`, build.log, and config.log to be attached. Thanks for your good work!