libstdc++.la: No such file or directory .. thread feedback

[yaneurabeya]

[curtis119]

[yaneurabeya]

Mmmk. I added the dirty symlink hack.

[Cintra]

[Donovan]

Thanks, my KDE 3.4 was erroring out, fix_libtool did it.

The forum search is poor, but thankfully the fix thread was the #1 search result on Google when I searched for the error message

Thanks again!

[yaneurabeya]

Hmmm... excellent. I didn't realize that I was getting that much coverage on the "FAQ" .

[gagern]

EDIT: solved this one, see below.

• emerging x11-libs/gtk+-2.6.7 (actually as part of update world) failed.
  
• executing fix_libtool_files.sh 3.4.3 did not help.
  
• switching between i686-pc-linux-gnu-3.3.5-20050130 and i686-pc-linux-gnu-3.4.3-20050110 including env-update and source /etc/profile did not help
  
• setting ACCEPT_KEYWORDS from ~x86 to x86 did not help.
  

[gagern]

HEUREKA!

OK, I guess you could call this plain stupidity . I did not read the fix_libtool_files.sh description properly, just looked at the code examples and plugged in my current version number. Once I called it correctly using the old version number, I got a lot of fixes, and gtk+ just did compile well, although I'm still doing the docs.

Maybe handling --help, -h and -? to produce the usage information as well would help a bit, because I got deeply worried when I called it with -h the first time and the thing obviously started some work I did not intend it to do. Otherwise I might have taken more time to read the usage information. I'm not trying to blame someone, just trying to make some sense of my strange "illiteracy".

[ulises]

Then, you execute the command "libtoolfix.sh gcc-3.3.4" ??
Can you put the exact steps do you use to fix this problem???

Thanks.

[gagern]

[ulises]

I did what you told me:

fix_libtool_files.sh 3.3.4
env-update
source /etc/profile

And fix all the problems with that lib!!

I am using gcc-3.4.3 and all works great now. Thanks for your help!

[Zanicar]

I had a similar problem emerging samba on a fresh install of 2005.0

It said that it couldn't find the directory... the version was correct, but it had i386 instead of i686 and fix_libtool_files.sh didn't fix the problem even if i did specify -oldarch as earlier in this thread.

I then simply created the directories it was looking for and copied my i686 lib to it... No problems emerging; just delete it afterwards so you won't get quirky behaviour when you update...

[qwertz]

I made a stage3 installation (from CD) -> stage3-pentium4-2005.0.tar.bz2.
In /etc/make.conf I didn't change the installation defaults:

[yaneurabeya]

Try running gcc-config -l and then select your current GCC version and try to recompile that last package.

The error you're receiving is completely different from the libstdc++.la file missing error I described.

It's not normal, but after you changed CHOST variable everything *should* be fine. Otherwise, start from scratch or rebuild a lot of your toolchain stuff since something got screwed up from when you went from your initial system build to where you are now.

[qwertz]

[yaneurabeya]

Ah, well I have an idea what the issue is but it's not really fixable without a lot of recompiling. For what it's worth I've seen tons of people have issues with stage 3 installs and I myself have never done a stage 3 install primarily for that purpose.

What you can do is try running the fix_libtool_files.sh script with the old host being i386. If that doesn't work, there's always /usr/portage/scripts/bootstrap.sh && emerge -e system && emerge -e world. It'll take a while, but at least it will fix issues with your system. Or if you're willing, just clear off your hard drive and run an install from stage 2. I dunno why but whoever does the stage 3 installs on whatever machine doesn't do it properly or something because issues like what you describe still pop-up.

[yaneurabeya]

Note: supposedly fix_libtool_files.sh has been modified (read https://bugs.gentoo.org/show_bug.cgi?id=23466 ), so maybe things have improved.

[qwertz]

[yaneurabeya]

I actually thought that non-stage 3 installs were the norm, but I suppose I could be wrong since I don't have figures.

As for the problem, I mentioned it. It's not so much as the stage 3 files are flawed, but possibly the compilation order/configuration performed by the devs (this is just purely speculation). I have no idea why, but it just seems like a lot of errors seem to crop up the further you 'go away' from stage 3 (remember: this is based on my personal experience only), so for stage 1 installs it seems like there are little issues with subsequent compilation since the system was created from scratch with a good foundation (assuming that the /etc/make.conf variables were setup correctly).

Like I said, I suggest forcing a bootstrap on your system. I know it will take a while, but it will most likely ensure fewer errors in the future.

[qwertz]

Thank you very much for your help. I'll try it with a stage 2 installation from scratch.

However, I'm quite frustated with Gentoo (first touch) since I don't like this "try this and that, maybe it works"-approach. I prefer knowing what I'm doing and having a stable system by design, not by accident. I't remembers me the way problems are solved under Windoze...
I never had inconsistencies and bad configured default settings with Debian all over the years. And I didn't expect this with Gentoo, neither.

It's a pity, since Gentoo implements many very innovative concepts and looked like a distribution just made for developers. But after the first steps:

[yaneurabeya]

Well, after the initial issues, finding out which way works for you is much easier. There isn't really a unified solution for everything I've learned, so you have to take everything in stride.

However, I don't like stage 3 with a passion because of the issues I've seen, so yeah... try stage 2. I worked with stage 2 quite a bit before doing stage 1 installs only and didn't really have any problems. The further from binary compiled code, the less likely you are going to have compilation errors methinks ...

[rhill]

there's a hugely improved version of fix_libtool_files.sh rewritten in python collecting dust in bugzilla. it makes two improvements - first it doesn't require a version number for an argument - and second it doesn't change the mtimes of files, which otherwise causes them to not get uninstalled with the package they belong to.

the bug is https://bugs.gentoo.org/show_bug.cgi?id=71265

the crappy thing is the patch gets overwritten every time gcc gets updated. =/
_________________
by design, by neglect
for a fact or just for effect

[rhill]

i got a request for instructions on how to use the script above so here goes.

1] grab the patch against fix_libtool_files.sh from this URL: https://bugs.gentoo.org/attachment.cgi?id=58311
2] patch the script

[qwertz]

[yaneurabeya]

Hmmm.... could be.