After doing an upgrade to my system from gcc-3.4.3-20050110 to gcc-3.4.4 it caused the next package to be emerged to fail. I tried using the fix_libtool_files.sh script but my memory was a bit off and I gave it the new arch instead of the old. I typed fix_libtool_files.sh 3.4.4. Since this didn't work I typed fix_libtool_files.sh and got the help message. At this point I tried fix_libtool_files.sh 3.4.3-20050110 no success I also tried it with 3.4.3, 3.4.3-20050110-r2 and 3.4.3-20050110-r1. At this point any attempt to use gcc-config to change to gcc-3.4.4 fails. And gcc-config -l list gcc-3.3.5 and 3.4.4 but no 3.4.3-20050110. I assume this is because minor changes are unmerged. But it has no marker next to any version listed showing me to not have any gcc set. also emerge fails always with the error message that it can't find libstdc++.so.6. I did verify that the file does exist in the 3.4.4 directory. I am typing this on the second machine so I can't get an accurate emerge info since the emerge command fails. Reproducible: Always Steps to Reproduce: 1.emerge gcc-3.4.4 2.fix_libtool_files.sh 3.4.4 3.fix_libtool_files.sh 3.4.3-20050110-r2 Actual Results: As stated above the system will not even execute an emerge. If you know how I can from this partialy broken system fix it to the point that I can run gcc-config and emerge again I would appreciate and answer. Expected Results: System shouldn't have misplaced the links to the libstdc++.so.6 file. Cannot give you an emerge info from the affected system since emerge is no longer working.
Same here. I upgraded from 3.4.3-20050110 to 3.4.4 I've lost the context but here are the errors I recorded. I think these ones appeared at the start of the next emerge: /usr/bin/gcc-config: line 496: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or directory * /usr/bin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110 /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110 doesnt exist I tried using gcc-config to select a different compiler dsd ~ # gcc-config 1 * Switching to i686-pc-linux-gnu-3.3.5-20050130 compiler ... /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/gcc-config: line 81: env: command not found * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile The workaround: Edit /etc/ld.so.conf, adding the correct path to the directory containing libstdc++.so.6, then re-run gcc-config.
Correction. Edit /etc/ld.so.conf, adding the correct path to the directory containing libstdc++.so.6, then run ldconfig, then run gcc-config.
ok well lemme try to explain this a little better... essentially I grabbed a 2005.0 stage3. did the following tar -jxpf stage3* chroot /mnt/gentoo /bin/bash env-update source /etc/profile emerge --sync emerge gentoo-sources emerge -auDv world after a handful of other ebuilds... python merged then gcc and then glibc was suppose to merge but here's where problem strikes. * Checking gcc for __thread support ... no * Could not find a gcc that supports the __thread directive! * please update to gcc-3.2.2-r1 or later, and try again. We know that's baloney cause the 2005.0 stage3 has gcc 3.3.5. So I tried to give it a little env-update love... # env-update /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory Well obviously gcc-config and env-update didn't update the environment correctly. So... # gcc-config 1 * Switching to i686-pc-linux-gnu-3.3.5-20050130 compiler... /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/gcc-config: line 1: env: command not found * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile And here we have it... /etc/ld.so.conf still points to the old gcc location. Modifying this to the correct updated location and then running ldconfig. Followed by an immediate gcc-config 1 and env-update and source /etc/profile is the only way to recover from this.. Not too good for a fresh out of the box x86 install following the 2005.0 handbook using the 2005.0 stages.. :( Daniel Drake confirms a similar issue but I believe he's going to post his stuff here.
*** This bug has been marked as a duplicate of 84961 ***
Thanks for the information. I was able to get the second box back up and running. I am in the process of upgrading my primary box at the moment. Just to make things a little easier on myself I am upgrading just GCC at first so I can verify my paths. I forgot about /etc/ld.so.conf . Its not a file that I manually handle because of emerge's scripts. So once again, I thank you all for you knowledge of unix in general and linux and gentoo in particular.
I'm pretty sure this is not a duplicate of bug 84961. Notice how dsd got this with libstdc++.so.6. I'm pretty sure this bug is about /etc/ld.so.conf not getting the right path to libstdc++.so.whatever, which breaks some pythons, not people removing libstdc++-v3 while python still uses it.
I also can
I also can´t see how it this a duplicate. Reopened.
*** Bug 95062 has been marked as a duplicate of this bug. ***
*** Bug 95013 has been marked as a duplicate of this bug. ***
Also not limited to gcc-3.4 (Bug 95013), failes with gcc-3.3.5.20050130-r1 as well.
I've gotten hit by this. Brand new machine x86 built today. Essentially emerge system killed it I think. How can this happen on the stable branch? Anyway, mine is more like Bug 95050 so maybe someone should mark that bug as a duplicate of this one. I tried Doug's instructions as best I could by modifying them for my version: "And here we have it... /etc/ld.so.conf still points to the old gcc location. Modifying this to the correct updated location and then running ldconfig. Followed by an immediate gcc-config 1 and env-update and source /etc/profile is the only way to recover from this.." 1) I added the last line: # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/local/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 2) I then ran ldconfig, but at the gcc-config 1 step it fights back so obviously I'm not doing this right: localhost root # gcc-config 1 * Switching to i686-pc-linux-gnu-3.3.5-20050130 compiler... /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/gcc-config: line 1: env: command not found * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory * /usr/bin/gcc-config: Could not get portage CHOST! [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile localhost root # Since this is aq brand new machine is there some way I can just load all the portage stuff off the CD again to recover, or has it gone too far for that to work now?
error: /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory workaround: edit /etc/env.d/05gcc changing all version numbers to 3.4.4 move /usr/lib/gcc-lib/i686-pc-linux-gnu/[oldversion] to 3.4.4 run source /etc/profile run LD_LIBRARY_PATH=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.4/ env-update
additional steps to fix the 3.4.4 libstdc++.so.6 missing bug: link libstdc++.so.6.0.3 files from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/ to /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 and libstdc++.so and also link them to /usr/lib then run env-update this fix was used when the libstdc++.so.6 is missing bug for kde-libs 3.4.1
My aborted emerge log. Python -> gcc-config -> gcc -> (dead). Might help track stuff down. 1117859666: >>> emerge (6 of 156) dev-lang/python-2.3.5 to / 1117859666: === (6 of 156) Cleaning (dev-lang/python-2.3.5::/usr/portage/dev-lang/python/python-2.3.5.ebuild) 1117859667: === (6 of 156) Compiling/Merging (dev-lang/python-2.3.5::/usr/portage/dev-lang/python/python-2.3.5.ebuild) 1117859856: === (6 of 156) Post-Build Cleaning (dev-lang/python-2.3.5::/usr/portage/dev-lang/python/python-2.3.5.ebuild) 1117859857: >>> AUTOCLEAN: dev-lang/python 1117859862: === Unmerging... (dev-lang/python-2.3.4-r1) 1117859864: >>> unmerge success: dev-lang/python-2.3.4-r1 1117859865: ::: completed emerge (6 of 156) dev-lang/python-2.3.5 to / 1117859865: >>> emerge (7 of 156) sys-devel/gcc-config-1.3.10-r2 to / 1117859865: === (7 of 156) Cleaning (sys-devel/gcc-config-1.3.10-r2::/usr/portage/sys-devel/gcc-config/gcc-config-1.3.10-r2.ebuild) 1117859866: === (7 of 156) Compiling/Merging (sys-devel/gcc-config-1.3.10-r2::/usr/portage/sys-devel/gcc-config/gcc-config-1.3.10-r2.ebuild) 1117859876: === (7 of 156) Post-Build Cleaning (sys-devel/gcc-config-1.3.10-r2::/usr/portage/sys-devel/gcc-config/gcc-config-1.3.10-r2.ebuild) 1117859877: >>> AUTOCLEAN: sys-devel/gcc-config 1117859882: === Unmerging... (sys-devel/gcc-config-1.3.8-r4) 1117859885: >>> unmerge success: sys-devel/gcc-config-1.3.8-r4 1117859886: ::: completed emerge (7 of 156) sys-devel/gcc-config-1.3.10-r2 to / 1117859886: >>> emerge (8 of 156) sys-devel/gcc-3.3.5.20050130-r1 to / 1117859886: === (8 of 156) Cleaning (sys-devel/gcc-3.3.5.20050130-r1::/usr/portage/sys-devel/gcc/gcc-3.3.5.20050130-r1.ebuild) 1117859887: === (8 of 156) Compiling/Merging (sys-devel/gcc-3.3.5.20050130-r1::/usr/portage/sys-devel/gcc/gcc-3.3.5.20050130-r1.ebuild) 1117861190: === (8 of 156) Post-Build Cleaning (sys-devel/gcc-3.3.5.20050130-r1::/usr/portage/sys-devel/gcc/gcc-3.3.5.20050130-r1.ebuild) 1117861204: >>> AUTOCLEAN: sys-devel/gcc 1117861209: === Unmerging... (sys-devel/gcc-3.3.5-r1) 1117861223: >>> unmerge success: sys-devel/gcc-3.3.5-r1 1117861223: ::: completed emerge (8 of 156) sys-devel/gcc-3.3.5.20050130-r1 to / 1117861223: >>> emerge (9 of 156) dev-util/dialog-1.0.20050206 to / 1117861223: === (9 of 156) Cleaning (dev-util/dialog-1.0.20050206::/usr/portage/dev-util/dialog/dialog-1.0.20050206.ebuild) 1117861224: === (9 of 156) Compiling/Merging (dev-util/dialog-1.0.20050206::/usr/portage/dev-util/dialog/dialog-1.0.20050206.ebuild) 1117861225: *** terminating.
Confirmed on an x86 system going from 3.3.5 to 3.3.5.20050130 Mark: /etc/ld.so.conf should only contain paths, so add the path of the parent directory, not the full path to the .so file itself.
(In reply to comment #15) > Confirmed on an x86 system going from 3.3.5 to 3.3.5.20050130 Hmm, eclass is broken? Never have had such issues before. :/
*** Bug 95117 has been marked as a duplicate of this bug. ***
*** Bug 95050 has been marked as a duplicate of this bug. ***
Explanation of the problem: python is compiled by default against libstdc++.so.X. During a gcc upgrade of the same SLOT, the path to libstdc++.so.X changes. Presumably there is python magic involved to handle the path changes, however python cannot run because it can't find libstdc++.so.X - this is where everything breaks. I've looked into fixing this but I'm not exactly sure what to do and I don't want to break anything further. Here's the relevant IRC conversation if it is of any use: 19:40 <@SpanKY> dsd_: building python with C++ support is just asking for trouble (and hey look, it is causing trouble) 19:42 <@dsd_> SpanKY: its more than that 19:43 <@dsd_> SpanKY: if you correct the paths in ld.so.conf then things start working 19:43 <@dsd_> its not automatically changing from 3.3.5 to 3.3.5-20050130 or whatever 19:43 <@SpanKY> *shrug* 19:43 <@dsd_> or is that because python breaks at that point in time..? 19:43 <@dsd_> its affecting every single stage1 installation and gcc upgrade 19:44 <@dsd_> !meta python 19:44 <+jeeves> dsd_: Package: dev-lang/python Herd: python Maintainer: liquidx@gentoo.org 19:44 <@dsd_> i'll see if we can get nocxx temporarily forced on 19:45 <@kloeri_> dsd_: forcing nocxx is fine but doesn't really solve gcc being broken.. 19:46 <@dsd_> kloeri_: it does, i think 19:46 <@kloeri_> dsd_: I've been through many gcc updates without any troubles 19:47 <@kloeri_> dsd_: so I haven't seen that happen myself at least 19:47 <@dsd_> kloeri_: which version of python is installed, and which USE flags? 19:48 <@dsd_> kloeri_: when did you last upgrade gcc, and does "ldd $(which python)" include libstdc++.so.X ? 19:48 <@kloeri_> dsd_: all the different python version on several different archs - all with -nocxx 19:48 <@kloeri_> dsd_: 10 hours ago and yes :) 19:50 <@kloeri_> dsd_: I upgraded from gcc-3.3.2 to 3.4.4 19:55 <+hydrogen> kloeri_, what I asked dsd_, and I am not quite sure of this, but the problem would not have appeared for you because 3.4.4 was in a different slot, so you did not lose the 3.3.x links, therefore not breaking it, correct? 19:56 <@kloeri_> hydrogen: could be.. but I've done quite a few upgrades/downgrades between 3.3.2 and 3.3.5 as well 19:58 <@Flameeyes> when you install <gcc3.4.4 you also get libstdc++-v3, which is added to the search path 19:59 <@Flameeyes> so when you change gcc you doesn't lost libstdc++.so.5 anyway edit: note that the above isn't relevent, when you experience this bug in the gcc-3.4 slot it complains about libstdc++.so.6 20:02 <@dsd_> Kugelfang: correct. but during an upgrade from 3.3.x to 3.3.y, the path to libstdc++.so.5 changes 20:02 <@Kugelfang> yes 20:02 <@dsd_> (i guess) there is python magic in place to update the paths 20:03 <@dsd_> but since python is compiled against that file in the first place it fails 20:03 <@dsd_> making more sense now 20:03 <@Flameeyes> dsd_, the solution can be running env-update *before* unmerging the old version 20:03 <@Kugelfang> dsd_: well then the ebuild should issue LD_LIBRARY_PATH=${new_path_to_libstdc++.so.5} gcc-config 1 20:03 <@Flameeyes> Kugelfang, no, env-update, gcc-config isn't needed 20:03 <@Kugelfang> or LD_LIBRARY_PATH="..:" env-update 20:04 <@Kugelfang> Flameeyes: right... 20:04 <@Flameeyes> [the other is to build python with nocxx :P] Could one of the toolchain maintainers please look into this? It is breaking every stage1 install and gcc upgrade (where the upgrade exists in the same slot).
CCing python maintainer for information reasons (although I don't think enforcing nocxx is a good solution...)
(In reply to comment #19) I
(In reply to comment #19) I´m pretty sure it worked without a hitch a few weeks ago (and even a few days ago!) - so the error must be somewhere else then in python.
This is what appears at the end of a (broken) gcc merge .. nothing really of interest --- !empty dir /lib/rcscripts/awk --- !empty dir /lib/rcscripts --- !empty dir /lib --- !empty dir /etc/env.d/gcc --- !empty dir /etc * Scanning libtool files for hardcoded gcc library paths... /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory :0: assertion failed: (/usr/bin/portageq envvar 'CHOST') | getline CHOST * Scanning libtool files for hardcoded gcc library paths... /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory :0: assertion failed: (/usr/bin/portageq envvar 'CHOST') | getline CHOST >>> Regenerating /etc/ld.so.cache... * Caching service dependencies...
Bug 93125 can probably give a more accurate picture about when this started to get broken.
*** Bug 93125 has been marked as a duplicate of this bug. ***
I think I have a fix.. Need to test it.. Give me 25 mins.
I believe a mistake is here: http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/toolchain.eclass?r1=1.162&r2=1.160 Behaviour has been changed, look at the bottom hunk (should_we_gcc_config) However, changing this back to "|| return 1" hasn't solved the problem either. :(
(In reply to comment #26) What about this one: http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/toolchain.eclass?r1=1.162&r2=1.161
What specifically about it? That diff is included inside mine. I posted the diff between 1.160 and 1.162, and you follow up with the diff between 1.161 and 1.162 ...?
(In reply to comment #28) > What specifically about it? Look at should_we_gcc_config() - just an idea
Sorry if I'm being slow. What exactly are you pointing out? I can't see how it is has different consequences from the diff that I posted. Both 1.161 and 1.162 give different behaviour for ROOT=/ compared to 1.160
Comment #26 does solve this. The reason it failed is because downgrading gcc is broken, but thats another issue, for tomorrow. gcc upgrades and stage1 installs will now be working - the fix is committed to CVS.
*** Bug 95261 has been marked as a duplicate of this bug. ***
*** Bug 95589 has been marked as a duplicate of this bug. ***
