Peter posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 12 Jan 2005 15:36:29 +0300:
> On Wed, 12 Jan 2005 14:29:17 +0300, Peter wrote: >> The problem was solved by changing profile again by hand. `gcc-config 1` > > Actually the problem is not solved... I can not compile > media-sound/zinf-2.2.5-r1 because of next error: > /bin/sh ../../../libtool --mode=link i686-pc-linux-gnu-g++ -O2 > -march=pentium4 -fomit-frame-pointer -pipe -mcpu=pentium4 -o mbcd-mdf.la > -rpath /usr/lib/zinf/plugins -module -avoid-version mbcd.lo -lz -lmusicbrainz > grep: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la: No such file or > directory > /bin/sed: can't read /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la: > No such file or directory > libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la' is not > a valid libtool archive I've previously worked around such problems temporarily by creating a symlink at the old location pointing to the new one. Thus, /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 -> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 This is a work-around, not a fix, as that shouldn't be necessary. However, it's effective when you just want to get the ****** emerge to work. It should still be bug filed. (Use bugs.gentoo.org for that. This isn't a bug tracking list here, altho it can help as with the above symlink suggestion when you get in a tough spot, altho that'd actually be better posted to the user group not devel.) Here's an explanation, much as I read it on the lists myself. Hopefully it's generally correct. I'm sure a dev will step in and correct me if not. The problem is libtool. Those *.la files are a hack for a historical problem that created new problems. Open them in a text editor and you will see they are a collection of a bunch of text info that helps the linker find the libraries it needs. Part of this info is library paths. When gcc is updated, a script is run that's supposed to find all the references to the old path and point it to the new location. Unfortunately, at this point, we are hacking hacks to fix hacks that were created to avoid problems with other hacks! <g> Unsurprisingly in such a situation, it doesn't always go the way it's supposed to go, and some of those *.la files tend to be missed and still point to the old location. When a new compile attempts to use the data in them to link against the library, it draws a blank, with the errors you posted the result. As I mentioned, there's a script to help fix these bad path pointers. As I mentioned, it is supposed to be run automatically when an upgrade is merged that causes some of them to be outdated. However, there's nothing stopping you from running it manually, and indeed that's the recommended fix in this case. If that fails, keep in mind that the *.la files in question /are/ text based, so you may try your hand at doing a manual grep for the offending string in your *.la files, then manually editing them to point to the right location, if worse comes to worse. The script is /sbin/fix_libtool_files.sh . Run it without any parameters to get a usage summary, or feed it to your favorite pager and take a look at the script to see what it does, if you prefer. Or... be lazy and create that symlink, and worry about cleaning up the mess (because you now have /more/ stuff pointing at the old location) later. <g> -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- [email protected] mailing list
