Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 377633 - sys-devel/gcc for amd64 with multilib does not add 32-bit version of libstdc++.so.6 to LDPATH
Summary: sys-devel/gcc for amd64 with multilib does not add 32-bit version of libstdc+...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://forums.gentoo.org/viewtopic-t-...
Whiteboard:
Keywords:
: 363523 370675 378293 378457 378487 378701 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-04 00:33 UTC by MaratIK
Modified: 2011-08-18 01:04 UTC (History)
26 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gcc-4.5.2-trace-env.log (gcc-4.5.2-trace-env.log,6.28 KB, text/plain)
2011-08-08 18:15 UTC, Ryan Hill (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MaratIK 2011-08-04 00:33:21 UTC
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
Comment 1 Ryan Hill (RETIRED) gentoo-dev 2011-08-05 23:11:17 UTC
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"
Comment 2 Tomasz Golinski 2011-08-06 18:12:57 UTC
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"
Comment 3 Francois Chenier 2011-08-07 04:36:28 UTC
(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
Comment 4 Maksym 2011-08-07 12:17:51 UTC
Same problem here (~amd64) after update
Comment 5 Ed Tomlinson 2011-08-07 19:01:35 UTC
Just to confirm that changing the env.d/gcc/* files as implied above & runing env-update gets the multilib ebuilds working again.
Comment 6 Zbyněk Kocur 2011-08-08 06:46:38 UTC
I have the same problem with gcc 4.5.3.
Comment 7 Thomas Niemeier 2011-08-08 08:24:32 UTC
I have the same problem with gcc 4.3.3, 4.4.6, 4.5.2 and 4.5.3.
Comment 8 Yuriy Dmitriev 2011-08-08 11:32:19 UTC
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(((((
Comment 9 MaratIK 2011-08-08 11:38:25 UTC
(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.
Comment 10 Yuriy Dmitriev 2011-08-08 14:41:54 UTC
(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))))
Comment 11 Ryan Hill (RETIRED) gentoo-dev 2011-08-08 17:29:09 UTC
I just rebuilt 4.5.3 and it fixed itself.  I think a wizard did it.
Comment 12 Ryan Hill (RETIRED) gentoo-dev 2011-08-08 17:31:34 UTC
*** Bug 370675 has been marked as a duplicate of this bug. ***
Comment 13 MaratIK 2011-08-08 17:34:48 UTC
(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/ ?
Comment 14 Ryan Hill (RETIRED) gentoo-dev 2011-08-08 17:37:58 UTC
toolchain.eclass:create_gcc_env_entry()

I think the upgrade path is broken.  I'm tracing it now.
Comment 15 Ryan Hill (RETIRED) gentoo-dev 2011-08-08 18:15:05 UTC
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.
Comment 16 Bernard Cafarelli gentoo-dev 2011-08-09 09:55:42 UTC
*** Bug 378293 has been marked as a duplicate of this bug. ***
Comment 17 Bernard Cafarelli gentoo-dev 2011-08-09 09:56:03 UTC
*** Bug 378357 has been marked as a duplicate of this bug. ***
Comment 18 Bernard Cafarelli gentoo-dev 2011-08-09 09:56:33 UTC
*** Bug 378457 has been marked as a duplicate of this bug. ***
Comment 19 Mark Loeser (RETIRED) gentoo-dev 2011-08-09 15:04:47 UTC
*** Bug 378487 has been marked as a duplicate of this bug. ***
Comment 20 Konstantin M 2011-08-10 19:09:46 UTC
re-emerging gcc-4.5.3 apparently fixed this problem for me as well now.
Comment 21 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2011-08-10 20:15:30 UTC
*** Bug 378701 has been marked as a duplicate of this bug. ***
Comment 22 Ryan Hill (RETIRED) gentoo-dev 2011-08-11 03:57:22 UTC
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
Comment 23 Michal F 2011-08-11 08:52:50 UTC
(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 !
Comment 24 MaratIK 2011-08-11 13:19:21 UTC
(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
Comment 25 Thomas Sachau gentoo-dev 2011-08-11 18:41:06 UTC
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).
Comment 27 Ryan Hill (RETIRED) gentoo-dev 2011-08-13 03:56:06 UTC
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.
Comment 28 SpanKY gentoo-dev 2011-08-15 04:59:54 UTC
(In reply to comment #22)

fwiw, that makes sense to me too
Comment 29 Alexey Shvetsov archtester gentoo-dev 2011-08-15 09:28:35 UTC
*** Bug 363523 has been marked as a duplicate of this bug. ***
Comment 30 MaratIK 2011-08-16 07:24:05 UTC
What about to revbump the latest stable version for amd64? (sys-devel/gcc-4.4.5)
Comment 31 Ryan Hill (RETIRED) gentoo-dev 2011-08-17 00:34:23 UTC
No, it went stable two months before this bug even existed.
Comment 32 MaratIK 2011-08-17 21:43:37 UTC
(In reply to comment #31)
What about users, who installed Gentoo during period when this bug was introduced and when it was fixed?
Comment 33 MaratIK 2011-08-17 21:43:56 UTC
(In reply to comment #31)
What about users, who installed Gentoo during period when this bug was introduced and when it was fixed?
Comment 34 Markos Chandras (RETIRED) gentoo-dev 2011-08-17 23:06:23 UTC
(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
Comment 35 Ryan Hill (RETIRED) gentoo-dev 2011-08-18 01:04:21 UTC
> (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.