Bug 123192 – libstdc++-v3 does not install lib32 libraries on a multilib profile

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Gabe Martin-Dempesy 2006-02-17 11:32:50 UTC]

From `equery f libstdc++-v3`: 
* Contents of sys-libs/libstdc++-v3-3.3.4: 
/etc 
/etc/env.d 
/etc/env.d/99libstdc++ 
/usr 
/usr/lib64 
/usr/lib64/libstdc++-v3 
/usr/lib64/libstdc++-v3/libstdc++.so.5 -> libstdc++.so.5.0.6 
/usr/lib64/libstdc++-v3/libstdc++.so.5.0.6 


There is no lib32 version of libstdc++.so.5.0.6 installed.  I have a multilib profile installed, and all the other necessary libraries are installing their 32 bit counterparts in /lib32; however libstdc++ is not.  I checked on the ebuild, and it is definitely including the "MULTILIB_OSDIRNAMES" portion during the compliation as dictated by the 'has_multilib_profile' check, and the output of the compiler mentions multilib several times.  However, it simply is not installing the libraries into lib32.


Portage 2.0.54 (hardened/amd64/multilib, gcc-3.4.4-hardenednopiessp, glibc-2.3.5-r2, 2.6.14-hardened-r3 x86_64) 
================================================================= 
System uname: 2.6.14-hardened-r3 x86_64 AMD Athlon(tm) 64 Processor 3000+ 
Gentoo Base System version 1.6.14 
dev-lang/python: 2.3.5-r2, 2.4.2 
sys-apps/sandbox: 1.2.12 
sys-devel/autoconf: 2.13, 2.59-r6 
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 
sys-devel/binutils: 2.16.1 
sys-devel/libtool: 1.5.22 
virtual/os-headers: 2.6.11-r2 
ACCEPT_KEYWORDS="amd64" 
AUTOCLEAN="yes" 
CBUILD="x86_64-pc-linux-gnu" 
CFLAGS="-march=athlon64 -pipe -O2" 
CHOST="x86_64-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-march=athlon64 -pipe -O2" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoconfig distlocks sandbox sfperms strict" 
GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.chem.wisc.edu/gentoo/" 
MAKEOPTS="-j2" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/usr/local/portage" 
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" 
USE="amd64 apache2 bzip2 chroot clearpasswd cli crypt curl doc expat gmp gpm hardened idn imagemagick imap ipalias jpeg justify libwww mhash mpm-prefork mysql ncurses nls notlsbeforeauth nptl pam pcre perl php pic png python qmail readline ruby sendfile session sftplogging spamassassin ssl symlink tcpd threads udev userlocales utf8 vchroot vhosts xml xml2 zlib userland_GNU kernel_linux elibc_glibc" 
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

[Comment 1 Simon Stelling (RETIRED) 2006-03-20 10:12:05 UTC]

You can find the 32bit libraries in app-emulation/emul-linux-x86-compat. I'm not sure why we would want libstdc++-v3 to build for more than one ABI, but either way we should fix it or clean out the ebuild, so I'm leaving this bug open. 

[Comment 2 Gabe Martin-Dempesy 2006-03-20 10:45:54 UTC]

Perhaps I'm confused about the intentions of multilib, but my impression was that it should automatically compile the 32 bit versions as well as the 64 bit versions.  The rest of the multilib enabled packages (eg: glibc) do this.

The description of emul-linux-x86-compat is: "emul-linux-x86 version of lib-compat, with the addition of a 32bit libgcc_s and the libstdc++ versions provided by gcc 3.3 and 3.4 for non-multilib systems", specifically noting "for non-multilib systems".

I feel like it is more consistent to change the libstdc++ ebuild to build a 32 bit version  (since it seems to be documented for that to be the intention) instead of changing the documentation on the ebuild.  If not, then what's the point of having multilib profiles?

[Comment 3 Simon Stelling (RETIRED) 2006-06-23 05:02:00 UTC]

well, libstdc++-v3 is not a multilib-enabled package. we'd do it this way if it wasn't such a hassle, i.e. if we had true multilib support. for the time being, we'll have to do with the emul-package