libstdc ++ - errors and remedies in Gentoo

This document presents the errors (especially encountered by those who do the installation in stage 3) related to libstdc ++. La - this tutorial is a translation of libstdc ++. La: No such file or directory - errors and tips from http: // forums. gentoo.org/ from the Documentation, Tips & Tricks section

I was thinking that I could contribute a useful post because, it seems that for some strange reasons, there are some problems that will not disappear and maybe this way the problem will be solved. Of course, read kallemej's FAQ first because it describes all the steps (in fact, both) needed to solve the problem. I don't like to go back on this issue, but I think what the other thread lacks is visibility and, by introducing a few keywords in this post, I hope I can make it easier to find than the others.

Here are the steps for the simplest solution, so let's let it go - What can the error in question look like:

grep: /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.la: No such file or directory -> / usr / $ {ERROR_ROOT_DIRECTORY} / $ {CHOST} / $ {GCC_VERSION} / libstdc ++. to

The command to be shown is the 'generalized' version of it, indicating the syntax of the command to be run as root

fix_libtool_files.sh $ {GCC_VERSION}

If there are still problems (probably due to another architecture, then the error message will appear with i386-pc-linux-gnu instead of i686-pc-linux-gnu) and you have read kallemej's advice on troubleshooting the architecture (see FAQ above), make sure you have not corrupted / modified the CHOST and CFLAGS variables by choosing inappropriate combinations for -march or -mcpu. Also, make sure that you have chosen the appropriate stage tarball that matches the architecture. See the installation manual for more details on the correct configuration.

Other possible solutions:

1) Try deleting ~ x86 (or maybe ~ amd64?) If you have something like this in the /etc/make.conf file next to the ACCEPT_KEYWORDS variable.
2) Here you will find a report of a bug that you may have if you have emerged to the latest gcc 3.4.3 (current version: 3.4.3.20050110): http://bugs.gentoo.org/show_bug.cgi ? id = 84324
3) If you have a problem with the recurring version (eg 3.4.3.3.4.3 ... etc) after running fix_libtool_files.sh, here are suggestions on how to fix it: http: // forums.gentoo.org/viewtopic-t-279136.html
4) If you still failed to solve the problem, post feedback / paste (in the thread specified below) with the result from emerge --info, from which stage you did installation and architecture
5) Last solution: if you fail in any way, make a symlink of the problem directory to the directory with gcc as below:
ln -sf / usr / lib / gcc / $ {CHOST} / usr / $ {ERROR_ROOT_DIRECTORY} / $ {CHOST} / $ {GCC_VERSION}
Only replace values as they appear after compile error. I do not encourage the use of this solution until all the others are exhausted because it is equivalent to the use of analgesics that do not solve the problem, only temporarily postpones it.

Note: you will need to restart the emerge (emerge --resume works fine in this case).

Some have also reported seeing MUCH versions longer than "3.4.3" (full gcc profile names, etc.), so it may be necessary to use something like "gcc-XXXXXXXXXX" instead of "3.4.3" for variable '$ {GCC_VERSION}'.

Moreover, if you are one of those who have a problem with changing the CHOST variable (for example, i386-pc-linux-gnu errors when using an i686-pc-linux-gnu (compiler) profile), then see dirtyepic's solution. which can solve the problem (or not). More details: http://forums.gentoo.org/viewtopic-t-321340.html

Tips for maintaining the toolchain (packages that allow the compilation of other packages in the system): As I mentioned before, I have very few problems with the thing this also works quite well for me with the packages I have (gcc 3.4.3, the latest glibc, as well as some unstable packages), considering that I rebuild the toolchain with bootstrap, then system and finally rebuild world.

So I suggest that every time you renew your gcc it is to do what was said above or, as kallemej suggests in its FAQ, but use the previous version of gcc with fix_libtool_files.sh and / or use the current version if upgrade from 3.4.3 to 3.4.3-r1 or something like this:

fix_libtool_files.sh 3.4.3

Although it seems insignificant, that -r1 can create problems when compiling packages if things are improperly hardcoded.

Also, if you upgrade glibc, I suggest you run

/usr/portage/scripts/bootstrap.sh && emerge -e system && emerge -e world 

because it decreases the likelihood of incompatibilities related to the glibc upgrade. You can use your favorite toolchain instead of the second command, because many have discovered various scripts that will help them automate the process. (see this thread for a script called tcupdate). I know it's somewhat redundant, but it seems to work for some when other solutions fail.

Good luck and maybe the compilations will be done without problems from now on

emerge that I saw affected by this problem (write me a private message if you have problems with others so I can add them to the list):

Amarok
avifile
beep-media-player
gcc (emerge --newuse -uD world) # this is due to some flags changing in gcc
gedit
Gnome
GTK
imagemagick
imlib
KDE
PHP
xine-lib