I created a new /boot and / partition tonight, and started a stage 1 install from my previous gentoo system. Boostrap went ok, as did emerge system. This morning I did emerge sync, and was asked for a new portage, which I installed ok. I tried emerge -pv world and saw a lot of new stuff, so did emerge world; emerge gcc gave me a correctly working gcc 3.3.2 .. then the system emerged new kernel-headers which failed ... now no binary on the system works e.g. $ man find /usr/bin/gtbl: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory groff: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
I had a simmilar problem. If I recall remerging gcc-config fixed the problem.
yes, `env-update && source /etc/profile` if that doesnt work, `emerge gcc-config` and try again
Can you please attached (if its still not fixed) you /etc/ld.so.conf, and also /etc/env.d/05gcc, /etc/env.d/gcc/*. Also try running ldconfig.
Also have a look here: http://bugs.gentoo.org/show_bug.cgi?id=39803
Can the portage guys please have a look here (also bug #39803 among others). Since 2.0.50* or maybe 2.0.49-something, I have been getting spurtious unmerging of packages (meaning autocleaning was not always run when expected - sometimes only with the next emerge call, or one after). I think this might be related. Comments? Suggestions?
*** Bug 39803 has been marked as a duplicate of this bug. ***
*** Bug 40294 has been marked as a duplicate of this bug. ***
Here is config files from Scott Blackwell: -- /etc/ld.so.conf -- # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /opt/blackdown-jdk-1.4.1/jre/lib/i386/ /opt/blackdown-jdk-1.4.1/jre/lib/i386/classic/ /opt/blackdown-jdk-1.4.1/jre/lib/i386/native_threads/ /usr/X11R6/lib /usr/games/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2 /usr/lib/mozilla /usr/lib/opengl/nvidia/lib /usr/local/lib -- -- /etc/env.d/05gcc -- PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" -- -- /etc/env.d/gcc/config -- CURRENT=i686-pc-linux-gnu-3.3.2 -- This clearly shows that pkg_post() of gcc-3.3.2-r5 was run _while_ gcc-3.2.3 was still installed, which is WRONG if you ask me. It should merge gcc-3.3.2, then unmerge 3.2.3, then run pkg_post() of 3.3.2 as it used to. Can anybody from the portage team explain _why_ this change was made?
As far as I'm aware that behavior hasn't changed in a really long time. It may be due to one last caching issue that TGL discovered... bug 40667 You could try that to see if it fixes the behavior... but I don't see that this has ever been the actual behavior... Portage _does_ unmerge exact package matches like you describe... but cleaning is a seperate phase, and not in between pre/post.
Ok, might it then be that env-update is not always run, or that env-update have some new stuff when to run ldconfig or when not? Why I am asking, is because most users confirm that the issues is fixed if they run env-update or gcc-config by hand (forums, mail with Scott) ...
and if one cannot run env-update? # env-update /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory running 'ldconfig' fixed the problem.
*** Bug 40868 has been marked as a duplicate of this bug. ***
To things, 1. Ive seen the "clean" issue 4 or 5 times myself. It might be every 5th or 6th emerge but after the first package is cleaned another was not emerged just then willwill be cleaned. once there were upto 5 or 6 packages cleaned like that. 2. I'm going to wipe this build and and redoit with portage logging enabled from the beginning. It will probably be late tommorow, to see if the problem shows again. See bug 40294 for my specificis.
I'm sorry. This maybe my fault.. emerge doesn't ldconfig after removing gcc-3.2.3 library directories. I fixed it in CVS.
*** Bug 40825 has been marked as a duplicate of this bug. ***
Well Masatomo Nakano probably has probably found the linking problem. In regards to the "unmerging clean" problem I looked in /var/log/emerge.log and found an ex: 1075280404: >>> starting rsync with rsync://217.72.114.100/gentoo-portage 1075280635: === Sync completed with rsync://217.72.114.100/gentoo-portage 1075280756: *** terminating. 1075306896: *** terminating. 1075306944: Started emerge on: Jan 28, 2004 08:22:24 1075306944: *** emerge --buildpkg portage 1075306945: >>> emerge (1 of 1) sys-apps/portage-2.0.50_pre20 to / 1075306945: === (1 of 1) Cleaning (sys-apps/portage-2.0.50_pre20::/home/portage/sys-apps/portage/portage-2.0.50_pre20.ebuild) 1075306946: === (1 of 1) Compiling/Packaging (sys-apps/portage-2.0.50_pre20::/home/portage/sys-apps/portage/portage-2.0.50_pre20.ebuild) 1075306968: === (1 of 1) Merging (sys-apps/portage-2.0.50_pre20::/home/portage/sys-apps/portage/portage-2.0.50_pre20.ebuild) 1075307032: === (1 of 1) Post-Build Cleaning (sys-apps/portage-2.0.50_pre20::/home/portage/sys-apps/portage/portage-2.0.50_pre20.ebuild) 1075307033: >>> AUTOCLEAN: sys-apps/portage 1075307033: --- AUTOCLEAN: Nothing unmerged. 1075307033: ::: completed emerge (1 of 1) sys-apps/portage-2.0.50_pre20 to / 1075307033: *** Finished. Cleaning up... 1075307045: === Unmerging... (sys-libs/glibc-2.3.3_pre20031222) 1075307061: >>> unmerge success: sys-libs/glibc-2.3.3_pre20031222 1075307061: === Unmerging... (dev-util/dialog-0.9_beta20031002) 1075307063: >>> unmerge success: dev-util/dialog-0.9_beta20031002 1075307063: === Unmerging... (dev-lang/perl-5.8.2-r1) 1075307078: >>> unmerge success: dev-lang/perl-5.8.2-r1 1075307078: === Unmerging... (x11-libs/openmotif-2.1.30-r3) 1075307082: >>> unmerge success: x11-libs/openmotif-2.1.30-r3 1075307082: === Unmerging... (sys-apps/pciutils-2.1.11) 1075307083: >>> unmerge success: sys-apps/pciutils-2.1.11 1075307083: === Unmerging... (dev-java/java-config-1.2.3) 1075307087: >>> unmerge success: dev-java/java-config-1.2.3 1075307088: *** exiting successfully. 1075307098: *** terminating. 1075307157: *** terminating. 1075307166: Started emerge on: Jan 28, 2004 08:26:06 1075307166: *** emerge --upgradeonly --deep --buildpkg --update system
gcc-3.3.2-r7 has the same problem. Running ldconfig fixes it.
When can we expect the new version of portage? This will be fairly critical during upgrades ...
Hiel, it is a portage problem ...
It has become a big problem. Do a search on the forums useing libstdc. The dirst page of 4 is about this prob.
It's out in 2.0.50-r1 for a bit now.
I will leave this open for a bit to make sure those with issues can resolve them. Thanks guys (portage team).
*** Bug 40955 has been marked as a duplicate of this bug. ***
*** Bug 28802 has been marked as a duplicate of this bug. ***
*** Bug 42022 has been marked as a duplicate of this bug. ***
we just ran into this bug on most of our infra boxes as we upgraded gcc. Should we change the gcc-3.3.2-r5 ebuild to depend on >=portage-2.0.50-r1?
*** Bug 43088 has been marked as a duplicate of this bug. ***
Here is what I did as I could not use emerge anymore to remerge gcc-config 1) Modify /etc/env.d/05gcc to reflect the changes in GCC version from 3.2.3 to 3.3.2. 2) Modify /etc/ld.so.conf to reflect the changes in GCC version 3) Run ldconfig (to make env-update work) 4) Run env-update And everything got fine !
Tried the above but get a problem with 05gcc line 4 which is"INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info" saying: raise Exception("ParseError: Invalid token (not '='): "+str(mycfg)+": line "+str(lex.lineno)) Exception: ParseError: Invalid token (not '='): /etc/env.d/05gcc: line 4 "
Here is my 05gcc file. I would rather look at lines above line 4 for errors in your file, a forgoten " for example ! PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2"
Thanks a lot! solved that one, a little embarrasing doe when you have done som e programming.
Oops, now I get a bug when compiling enchant 1.1.2 (for Gnome). See bug 43107.
Me too! I also had to follow the same steps as Fabien Fivaz in comment #28. env-update now works. I haven't yet tested the system more to see if anything else is broken.
Right. Now that I've done that (comment #28 / comment #33), I can't compile _anything_. (P.S. -- updatedb && locate config.log doesn't show anything. Where's my config.log?) >>> emerge (1 of 34) sys-apps/gawk-3.1.3-r1 to / >>> md5 src_uri ;-) gawk-3.1.3.tar.gz >>> Unpacking source... >>> Unpacking gawk-3.1.3.tar.gz to /var/tmp/portage/gawk-3.1.3-r1/work >>> Source unpacked. * Building gawk ... configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i686-pc-linux-gnu-strip... no checking for strip... strip checking for egrep... grep -E checking for bison... bison -y checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. !!! ERROR: sys-apps/gawk-3.1.3-r1 failed. !!! Function src_compile, Line 42, Exitcode 77 !!! (no error message)
ah! sorry. ignore the previous comment. It does work. I just didn't change all the 05gcc paths the first time.
I think that this is a very good example, that shows wee need static linked package managment system that works even we corrupt glibc. Our package managment system depents on too many libraryes. We can look at rpm. If system is broken we only need static shell, and rpm binary. In emerge case we need <list too long, skiped>
we should implement proper USE flag logic of the already existing use flag "static". This flag is of particular interest to the hardened team also. the USE flag "static" could be triggering AUTOMATIC building of critical packages like those containing bash, tar and cp in a static fashion, additionally it might be wise to let all profiles include the sash if that is not done already. it is all about error resistance and we can give the user a certain choice and level of control over the packages if we use the "static" USE flag to decide upon that. please feel free to forward me a wishlist where packages should honour the USE flag for "static" to generate a proper bulletproof way of "recovering" from human mistakes, most often rolling in quickpackages you created before and saved to a cdrom or on disk ;-) thanks, Alex
While updating the portage system my box pulled in gcc-3.3.2-r5 and failed to update the /etc/env.d/05gcc file causing everything to break. Couldn't do an emerge gcc-config because emerge was also broken. Had to edit the ld.so.conf file manually. This should really be fixed.
Pappy: the most wanted would be python
What I want to know is how this bug was allowed to get into the stable Gentoo!!!!! Well.....??? Thanks
This has been fixed for a while.
I've got this problem too. Compiling ghostscript: /bin/sh <./obj/ldt.tr ./obj/imain.o(.text+0x290e): In function `gs_main_tempnames': : undefined reference to `rpl_malloc' ./obj/icc.o(.text+0x1b71): In function `icmAllocStd_malloc': : undefined reference to `rpl_malloc' ./obj/gdevifno.o(.text+0x660): In function `initwriteimage': : undefined reference to `rpl_malloc' ./obj/dscparse.o(.text+0xd559): In function `dsc_parse_process_colours': : undefined reference to `rpl_malloc' ./obj/dscparse.o(.text+0xd8c9): In function `dsc_parse_custom_colours': : undefined reference to `rpl_malloc' ./obj/dscparse.o(.text+0xdc47): more undefined references to `rpl_malloc' follow /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so: undefined reference to `_Unwind_Resume_or_Rethrow@GCC_3.3' collect2: ld returned 1 exit status make: *** [bin/gs] Error 1 # gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions--enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3--with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
