sys-devel/gcc for amd64 with multilib does not add 32-bit version of libstdc++.so.6 to LDPATH. So, I can't run 32-bit apps like acroread. Reproducible: Always Steps to Reproduce: sudo emerge =sys-devel/gcc-4.4.5:4.4 =sys-devel/gcc-4.5.2:4.5 (Btw, sys-devel/gcc-4.4.5 is keyworded as amd64, and sys-devel/gcc-4.4.5 is keyworded as ~amd64) I'm not only the one who faced with this bug. See: http://forums.gentoo.org/viewtopic-t-887562-start-0-postdays-0-postorder-asc-highlight-.html Actual Results: $ cat /etc/env.d/gcc/* | grep LDPATH LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2" Expected Results: $ cat /etc/env.d/gcc/* | grep LDPATH LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/32" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32" Dates of emerging that packages are: $ genlop gcc | tail -n 3 Fri Jun 24 23:32:06 2011 >>> sys-devel/gcc-4.5.2 Thu Jul 28 01:38:23 2011 >>> sys-devel/gcc-4.4.5
Odd. $ cat /etc/env.d/gcc/* | grep LDPATH LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.6" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.6" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/32" LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2-pre9999:/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2-pre9999/32"
Just emerged gcc-4.5.3 today and run into the same problem on two machines: cat /etc/env.d/gcc/* | grep LDPATH LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3"
(In reply to comment #2) > Just emerged gcc-4.5.3 today and run into the same problem on two machines: Same problem after upgrading to gcc-4.5.3
Same problem here (~amd64) after update
Just to confirm that changing the env.d/gcc/* files as implied above & runing env-update gets the multilib ebuilds working again.
I have the same problem with gcc 4.5.3.
I have the same problem with gcc 4.3.3, 4.4.6, 4.5.2 and 4.5.3.
I confirm bug. $ googleearth ./googleearth-bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory $ skype ./skype: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory modifications /etc/env.d/* have no effects(((((
(In reply to comment #8) > modifications /etc/env.d/* have no effects((((( As temporary fix you can change /etc/env.d/05gcc-x86_64-pc-linux-gnu in such way: Change string in that file from (change to your appropriate paths depending on your gcc version): LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5" To: LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/32" After that run # env-update And then in console, where you starts skype or googleearth $ source /etc/profile Or restart X-session.
(In reply to comment #9) > (In reply to comment #8) > > > modifications /etc/env.d/* have no effects((((( > > As temporary fix you can change /etc/env.d/05gcc-x86_64-pc-linux-gnu in such > way: > > Change string in that file from (change to your appropriate paths depending on > your gcc version): > LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5" > > To: > LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/32" > > After that run > # env-update > > And then in console, where you starts skype or googleearth > $ source /etc/profile > > Or restart X-session. Thanks)))) working))) many many thx))))
I just rebuilt 4.5.3 and it fixed itself. I think a wizard did it.
*** Bug 370675 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > I just rebuilt 4.5.3 and it fixed itself. I think a wizard did it. Which eclass creates files under /etc/env.d/gcc/ ?
toolchain.eclass:create_gcc_env_entry() I think the upgrade path is broken. I'm tracing it now.
Created attachment 282597 [details] gcc-4.5.2-trace-env.log We're testing the existence of LIBPATH/${path} before the files are merged to the file system. 696 if is_multilib ; then 697 LDPATH="${LIBPATH}" 698 for path in 32 64 ; do 699 [[ -d ${LIBPATH}/${path} ]] && LDPATH="${LDPATH}:${LIBPATH}/${path}" 700 done 701 else So on an up/downgrade the test will always return false. This was exposed by http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.457&r2=1.458 Previously the `&& ! has_multilib_profile` condition meant we were normally taking the else branch instead.
*** Bug 378293 has been marked as a duplicate of this bug. ***
*** Bug 378357 has been marked as a duplicate of this bug. ***
*** Bug 378457 has been marked as a duplicate of this bug. ***
*** Bug 378487 has been marked as a duplicate of this bug. ***
re-emerging gcc-4.5.3 apparently fixed this problem for me as well now.
*** Bug 378701 has been marked as a duplicate of this bug. ***
I don't have time to test this but it should be as easy as --- toolchain.eclass 8 Jul 2011 11:35:01 -0000 1.461 +++ toolchain.eclass 11 Aug 2011 03:56:13 -0000 @@ -695,7 +695,7 @@ if is_multilib ; then LDPATH="${LIBPATH}" for path in 32 64 ; do - [[ -d ${LIBPATH}/${path} ]] && LDPATH="${LDPATH}:${LIBPATH}/${path}" + [[ -d ${D}${LIBPATH}/${path} ]] && LDPATH="${LDPATH}:${LIBPATH}/${path}" done else local MULTIDIR
(In reply to comment #11) > I just rebuilt 4.5.3 and it fixed itself. I think a wizard did it. This worked for me too, thanks !
(In reply to comment #22) > I don't have time to test this but it should be as easy as > > --- toolchain.eclass 8 Jul 2011 11:35:01 -0000 1.461 > +++ toolchain.eclass 11 Aug 2011 03:56:13 -0000 > @@ -695,7 +695,7 @@ > if is_multilib ; then > LDPATH="${LIBPATH}" > for path in 32 64 ; do > - [[ -d ${LIBPATH}/${path} ]] && > LDPATH="${LDPATH}:${LIBPATH}/${path}" > + [[ -d ${D}${LIBPATH}/${path} ]] && > LDPATH="${LDPATH}:${LIBPATH}/${path}" > done > else > local MULTIDIR Thanks, works for me
Any update, when this gets fixed in main tree? This also causes compile failures, when cross-compiling packages on amd64 for x86 (like users of multilib-portage do).
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1.461&r2=1.462
To stop this from being a huge pain in the ass for a long time I'm forcing rev bumps for all versions since Apr 10.
(In reply to comment #22) fwiw, that makes sense to me too
*** Bug 363523 has been marked as a duplicate of this bug. ***
What about to revbump the latest stable version for amd64? (sys-devel/gcc-4.4.5)
No, it went stable two months before this bug even existed.
(In reply to comment #31) What about users, who installed Gentoo during period when this bug was introduced and when it was fixed?
(In reply to comment #32) > (In reply to comment #31) > What about users, who installed Gentoo during period when this bug was > introduced and when it was fixed? That's a fair point. Please re-consider your decision about a revbump on stable tree
> (In reply to comment #31) > What about users, who installed Gentoo during period when this bug was > introduced and when it was fixed? No one installing Gentoo during this timeframe was upgrading, since 4.4.5 was already the stable version on the installation media (weekly snapshots, remember). Anyone switching to ~arch after installing is already covered by one of the other revbumps.