I've been having a problem with gcc not creating any libstdc++.so libstdc++.so.5 or libstdc++.so.5.0.2. I first had the problem when upgrading to gcc-config and having a problem with wrapper. Azarah helped me with the problem with wrapper, but upon emerging gcc, i had no libstdc++.so.5, which python (and thus emerge) required. seemant built a binary for me, and i have extracted it and got a gcc working. Now, even if i try to emerge the same version of gcc(3.2.1-r6, btw), it never seems to install the libstdc++.so's, but the ones from the binary I got from seemant are still in place and let applications run. However, this seems to be the cause of problems i am having relating to undefined versioned symbol time_put_w@@GLIBCPP_3.2 when compiling things like mozilla, aspell, and arts. I assume this because that is the only place I can find that string time_put_w@@GLIBCPP_3.2 If I just untar the binary I can compile the apps, and everything works with that, but I cannot upgrade gcc anymore. So I'm wondering what I can do to fix this. I guess maybe I should just point libstdc++.so.5 to something else? I don't know. I'll post the output of emerge gcc after this, maybe you can see something there.
Created attachment 7522 [details] output of emerge gcc, note no libstdc++.so files
is this a system you upgraded from 1.2 to 1.4 ?
Yes, this is an upgrade from 1.2 to 1.4.
SpanKY, can you still remember if that upgrade docs/scripts from carpaski/mkennedy is still around somewhere ?
http://www.gentoo.org/doc/en/upgrade-to-gentoo-1.4.xml http://cvs.gentoo.org/~carpaski/system_update/
Well, this is what I did in the first place to upgrade to 1.4. Was there a problem doing it this way? I had no problems for a long long time, then started getting errors about the time_put_w symbol. Should I go through all this again?
No, its rather a problem upgrading from gcc2 to gcc3. There are usually weird problems, etc. You could try to do the whole thing again, else maybe do a fresh install ?
Ok, going through all those steps again fixed it up. gcc now makes the libstdc++ files when it built using those scripts. I only got through step 3 before I tested this, but it looks ok, so far. I'm excited now that my system is all better :) Thanks for your help.
Well, I gotta report my system is still not generating the libstdc++.so.* files whenever a new gcc comes out. I can't find what is causing this. I have tried different things and some things work. One time it was suggested recompiling binutils and then gcc, and gcc did create the files after that, but again when a new gcc came out, the files were missing again. I even went through the same steps that were suggested and it didn't work again. Is there something I can try to see why these files aren't being created? I'm pretty much refusing to re-install as this is the only problem I have.
Basically remerge gcc-3.2.2 after you had done a 'emerge rsync', and run: # fix_libtool_files.sh 3.2.1 For more help, just run the script: --------------------------------------------- nosferatu devfsd # fix_libtool_files.sh Usage: fix_libtool_files.sh <old-gcc-version> Where <old-gcc-version> is the version number of the previous gcc version. For example, if you updated to gcc-3.2.1, and you had gcc-3.2 installed, run: # fix_libtool_files.sh 3.2 nosferatu devfsd # *** This bug has been marked as a duplicate of 15025 ***
You have 'static' in your USE flags ....
Yep, taking out the static use flag fixed it right up. Should it fail if static is in the use flags, though? I heard it doesn't do anything on 3.2, so I shouldn't use it anyway. Well, thanks again for helping me with this.
Ill fix it some time to not compile static if c++ compiler are build or maybe totally remove it.
