From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E1Voy-0005qY-EH for garchives@archives.gentoo.org; Sat, 06 Aug 2005 21:03:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j76L12GG002161; Sat, 6 Aug 2005 21:01:02 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j76L11Fj009200 for ; Sat, 6 Aug 2005 21:01:01 GMT Received: from localhost ([127.0.0.1]) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E1Vmv-0008U1-Ey for gentoo-amd64@lists.gentoo.org; Sat, 06 Aug 2005 21:01:01 +0000 Subject: Re: [gentoo-amd64] Re: gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ? From: Jeremy Huddleston To: gentoo-amd64@lists.gentoo.org In-Reply-To: References: <1123237235.11188.36.camel@echelon.zagamma.vpn> <1123346597.11655.11.camel@cloud.outersquare.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NeiJqYC29H1pXt7y2dsY" Date: Sat, 06 Aug 2005 14:01:01 -0700 Message-Id: <1123362061.11745.7.camel@cloud.outersquare.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Archives-Salt: 57249c38-eb05-4309-8f35-6557d80e1d9e X-Archives-Hash: 032511c820c772d01dad634a45e03e12 --=-NeiJqYC29H1pXt7y2dsY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > BTW, I use FEATURES=3Dbuildpkg, so after initial compile, switching glibc= s > back to the old gentoo approved 2.3.5-rX compiled with a gentoo approved > gcc-3.4.4, is simply a matter of emerge -K-ing the desired glibc. That's > really the only reason I'm daring enough to be running the still > hard-masked snapshot in the first place. With emerge -K, it's almost as > simple as a glibc-config, parallel to gcc-config, would be, and in some > ways less problematic, given the fact that since I've compiled KDE agains= t > gcc-4's libstdc++, every time I gcc-config back to 3.4.x, certain KDE app= s > (generally, anything using khtml, so not only Konqueror, but kweather, > and a few others) refuse to work correctly, until I gcc-config back to a > gcc-4.x once again. Yeah... uh... that's a known PITA issue... HOPEFULLY everything compiled against the 3.4 libstdc++ should work with the 4.0 libstdc++. You can get around this particular issue by creating /etc/env.d/01usegcc4stdcpp to force the loader to use the gcc4 libs: LDPATH=3D/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.1:/usr/lib/gcc/x86_64-pc-linu= x-gnu/4.0.1/32 Then run env-update You can check that it's using the gcc4 libstdc++ by doing: ldd /usr/kde/3.4/bin/konqueror | grep stdc++ --=-NeiJqYC29H1pXt7y2dsY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBC9SUNOpjtAl+gMRURAnMPAKCP77lsiJfp2xgEZu5Lsks1wn4DLwCgjC7h v7qdTPyXqxOIWCSVLbXawHw= =F1LB -----END PGP SIGNATURE----- --=-NeiJqYC29H1pXt7y2dsY-- -- gentoo-amd64@gentoo.org mailing list