Ironically, sys-apps/portage installs itself incorrectly for multilib amd64 systems, by trying to put parts of itself in /usr/lib instead of /usr/lib64. Reproducible: Always Steps to Reproduce: 1.FEATURES=multilib-strict emerge portage 2. 3. portage log of failed emerge attached
Created attachment 48704 [details] log of failed emerge
what profile are you using? Can yo emerge --sync and retry? Are you overriding MULTILIB_STRICT_DENY in your /etc/make.conf? /usr/lib/portage/bin/tbz2tool is an executable, si it shouldn't be matching the check.
Now I'm sorry for skipping the emerge --info. [Actually, looking at it below, it's not easy to tell what's the issue.] I am using hardened toolchain (though not hardened profile). Hardened toolchain makes "shared object" files instead of regular elf executables. I think the flag in the elf header is ET_DYN. It makes PaX more effective. Portage 2.0.51-r13 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-crudfactory-r4 x86_64) ================================================================= System uname: 2.6.10-crudfactory-r4 x86_64 AMD Athlon(tm) 64 Processor 3400+ Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 16 2005, 23:41:56)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.6.3, 1.5, 1.8.5-r2, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1, 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2, 1.3.5 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-pipe -march=athlon64 -Os -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-pipe -march=athlon64 -Os -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks multilib-strict sandbox" GENTOO_MIRRORS=" ftp://mirrors.tds.net/gentoo http://gentoo.eliteitminds.com ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://localhost/gentoo-portage" USE="amd64 X X509 aalib acl acpi alsa apache2 arts artswrappersuid audiofile avi berkdb bitmap-fonts bonobo caps cdparanoia cdr chroot crudhard crypt cscope cups curl divx4linux doc dvd dvdr emacs emul-linux-x86 encode erandom esd f77 faad fam flac foomaticdb fortran fpx freetype gdbm gif gimpprint gmp gpm graphviz gstreamer guile hardened hardenedphp httpd imagemagick imlib innodb ipv6 jack jack-tmpfs jbig jp2 jpeg kde lcms libwww live lzo lzw lzw-tiff mad maildir mbox mikmod mng motif mozcalendar mozilla mozp3p mozsvg mozxmlterm mpeg mpeg2 multilib mysql nas ncurses network nntp nodrm nptl nptlonly objc ogg oggvorbis opengl oss pam pcre pdflib perl php pic pie png portaudio ppds python qt quicktime quotes readline rtc scanner sdl slang spell sqlite ssl stream svg tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts usb userlocales vcd vim-with-x vlm vorbis wmf xface xml xml2 xmms xpm xprint xrandr xv xvid zlib" Unset: LDFLAGS
Can you try again? What is the output of 'file /var/tmp/portage/portage-2.0.51-r13/image///usr/lib/portage/bin/tbz2tool' for you?
/var/tmp/portage/portage-2.0.51-r13/image///usr/lib/portage/bin/tbz2tool: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped Same as a shared library. To my surprise, when I tried running /lib/libc-2.3.4.so it actually worked, printing a description of the library, so maybe it's not so weird for shared objects to be executable on Linux.
Ok, well multilib-strict is mainly for developers to FIND problems and correct them... it's not really needed by end users, so if you use hardened toolchain, then you should just turn off multilib-strict. Thanks for finding this, and sorry there's no easy solution. I hate to loose testers =(
There's not really a need to lose testers just because they have a "hybrid hardened" system. It just means they'd have to be more discriminating about which cases to report. If the stuff being installed includes files ending in .so, for instance, I'd think that should be reported, no? In nearly all cases, anyway, I would think.
