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

[yaneurabeya]

imlib2 error....

Code: Select all

cd /usr/lib/gcc/i686-pc-linux-gnu
ls

I have gcc-3.4.3 installed but it's listed as "3.4.3-20050110" I put a symlink to it like this:

Code: Select all

ln -s /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3

imlib2 compiles fine now.

I suppose you could symlink the new version every time you upgraded gcc, but it's unnecessary considering that issues like this *shouldn't* (and I stress shouldn't) occur.

[curtis119]

I suppose you could symlink the new version every time you upgraded gcc, but it's unnecessary considering that issues like this *shouldn't* (and I stress shouldn't) occur.

I agree. Things like this shouldn't happen but they do anyway.

[yaneurabeya]

Mmmk. I added the dirty symlink hack.

[Cintra]

Mmmk. I added the dirty symlink hack.

tutt tutt!

[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.

Code: Select all

# emerge -ua world
/bin/sh ../libtool --mode=link i686-pc-linux-gnu-gcc  -march=prescott -O2 -Wall   -o libpixbufloader
-tiff.la -rpath /usr/lib/gtk-2.0/2.4.0/loaders -avoid-version -module  io-tiff.lo -ltiff libgdk_pixb
uf-2.0.la -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm
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 director
y               
libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la' is not a valid libtool archiv
e               
make[4]: *** [libpixbufloader-tiff.la] Error 1

Code: Select all

# fix_libtool_files.sh 3.4.3
 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/9] Scanning /lib ...
 *   [2/9] Scanning /usr/lib ...
 *     FIXING: /usr/lib/libflash.la ...[]
 *     FIXING: /usr/lib/libgdkmm-2.4.la ...[]
 *     FIXING: /usr/lib/libknetmon.la ...[]
 *     FIXING: /usr/lib/inkscape/plugins/libgrid.la ...[]
 *     FIXING: /usr/lib/inkscape/plugins/libgimpgrad.la ...[]
 *     FIXING: /usr/lib/libpangomm-1.4.la ...[]
 *     FIXING: /usr/lib/libglibmm-2.4.la ...[]
 *     FIXING: /usr/lib/libsigc-2.0.la ...[]
 *     FIXING: /usr/lib/libatkmm-1.6.la ...[]
 *     FIXING: /usr/lib/libgtkmm-2.4.la ...[]
 *     FIXING: /usr/lib/libglibmm_generate_extra_defs-2.4.la ...[]
 *   [3/9] Scanning /opt/sun-jdk-1.5.0.02/jre/lib ...
 *   [4/9] Scanning /usr/games/lib ...
 *   [5/9] Scanning /usr/i686-pc-linux-gnu/lib ...
 *   [6/9] Scanning /usr/kde/3.3/lib ...
 *   [7/9] Scanning /usr/kde/3.4/lib ...
 *   [8/9] Scanning /usr/local/lib ...
 *   [9/9] Scanning /usr/qt/3/lib ...

Code: Select all

# gcc-config -l
[1] i686-pc-linux-gnu-3.3.5-20050130
[2] i686-pc-linux-gnu-3.3.5-20050130-hardened
[3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp
[5] i686-pc-linux-gnu-3.4.3-20050110 *
[6] i686-pc-linux-gnu-3.4.3-20050110-hardened
[7] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie
[8] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp

Code: Select all

# locate libstdc++.la
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/libstdc++.la
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.la

Code: Select all

# emerge info
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11.7 i686)
=================================================================
System uname: 2.6.11.7 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.6.10
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Mar 20 2005, 19:31:56)]
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r8
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=prescott -O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=prescott -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.inode.at/ rsync://ftp.snt.utwente.nl/gentoo ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LINGUAS="en de"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 X aac aalib acpi alsa apache2 apm arts auctex avi bash-completion bcmath berkdb bigger-fonts bitmap-fonts bzip2 bzlib c++ cairo cdparanoia cdr chroot crypt css cups curl dba dhcp divx4linux dnd doc dts dv dvd emboss encode escreen esd ethereal exif faad fam fastcgi fbcon ffmpeg fftw flac flatfile foomaticdb fortran ftp gcc-libffi gcj gd gdbm gif gimp gimpprint gpm graphviz gs gtk gtk2 guile imagemagick imlib ipv6 java jpeg junit kde latex libg++ libwww lirc lzo lzw mad maildir mailwrapper mikmod mime mjpeg mmx motif mozilla moznocompose mozxmlterm mp3 mpeg mpeg2 mplayer mpm-worker mule mysql ncurses net network nls no-old-linux nptl odbc ogg oggvorbis opengl operanom2 oss pam pdf pdflib perl php pic pie plotutils png postgres povray procmail python qt quicktime rdesktop readline real recode samba sasl savedconfig sdl slang smime sndfile sockets sox spell sse sse2 ssl svga symlink tcltk tcpd tetex threads tiff tokenizer transcode translator truetype truetype-fonts type1 type1-fonts unicode usb userlocales utf8 v4l v4l2 vorbis wmf xanim xchattext xemacs xine xml xml2 xmms xv xvid xvmc zlib linguas_en linguas_de userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

[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]

Code: Select all

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

Then, fix_libtool_files.sh lists a bunch of files, longer than those posted in this thread here, marked by [v] (or something like this) instead of [] like before. I guess the other two lines are not really needed, but I think I did them anyway, so I list them here for complentes.

I was really curious, why the tools kept talking about this old version, so I grep'ed some relevant directories (basically those listed by fix_libtool_files.sh istelf) and found thousands of files still containing the string "3.3.4/libstdc". So I guessed that there was something wrong with the operation of fix_libtool_files.sh, had a look at the sources, and finally noticed what I had not when looking at the usage instructions, that you should plug in the old version you want to replace.

I figure the current version is derived from the gcc-config anyway.

[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:

Code: Select all

CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j3"

The installation from pre-compiled packages worked.
But almost every second ebuild I wanted to install from the sources fails. E.g.:

Code: Select all

x11-libs/Xaw3d-1.5-r1:
  gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"

app-portage/guitoo-0.50.01:
  libtool: link: cannot find the library `//usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5/libstdc++.la'

kde-base/kdelibs-3.3.2-r9:
  /bin/sed: can't read /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5/libstdc++.la: No such file or directory
  libtool: link: `/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5/libstdc++.la' is not avalid libtool archive

I tried the tricks mentioned in http://forums.gentoo.org/viewtopic.php?t=279020 - they helped partially:

Code: Select all

> fix_libtool_files.sh 3.3.5
 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/6] Scanning /lib ...
 *   [2/6] Scanning /usr/lib ...
 *     FIXING: /usr/lib/libtiffxx.la ...[]
 *   [3/6] Scanning /usr/i686-pc-linux-gnu/lib ...
 *   [4/6] Scanning /usr/kde/3.3/lib ...
 *     FIXING: /usr/kde/3.3/lib/libmcop.la ...[]
 [...]
 *     FIXING: /usr/kde/3.3/lib/libkmedia2.la ...[]
 *   [5/6] Scanning /usr/local/lib ...
 *   [6/6] Scanning /usr/qt/3/lib ...
> env-update

Result: same errors as before.

Code: Select all

> /sbin/fix_libtool_files.sh 3.3.5 --oldarch i386-pc-linux-gnu
 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/6] Scanning /lib ...
 *   [2/6] Scanning /usr/lib ...
 *     FIXING: /usr/lib/libfam.la ...[cv]
 *     FIXING: /usr/lib/gnome-vfs-2.0/modules/libfile.la ...[cv]
 *     FIXING: /usr/lib/libaspell.la ...[cv]
 *     FIXING: /usr/lib/libpspell.la ...[cv]
 *     FIXING: /usr/lib/libtiffxx.la ...[]
 *   [3/6] Scanning /usr/i686-pc-linux-gnu/lib ...
 *   [4/6] Scanning /usr/kde/3.3/lib ...
 *     FIXING: /usr/kde/3.3/lib/libmcop.la ...[]
 [...]
 *     FIXING: /usr/kde/3.3/lib/libkdeinit_kedit.la ...[cv]
 *   [5/6] Scanning /usr/local/lib ...
 *   [6/6] Scanning /usr/qt/3/lib ...
> env-update

Result: Xaw3d failed with same errors as before, kdelibs and guitoo worked.

1. Is that normal (that so many ebuild do not work, even on default installations)?
2. If not: What did I make wrong?
3. If yes: How can the problem be fixed?

It's important for me to understand the reason for this things:
If I made some mistake when installing I will make a correct reinstall to get a clean system.
If there are errors in the ebuild I would like to contribute for solving them (bug reports, correcting ebuilds - what suggested).

[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]

Try running gcc-config -l and then select your current GCC version [...]

Code: Select all

> gcc-config -l
[1] i686-pc-linux-gnu-3.3.5-20050130 *
[2] i686-pc-linux-gnu-3.3.5-20050130-hardened
[3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp

> gcc --version
gcc (GCC) 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)
Copyright © 2003 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.

So, I guess this is right.

[...] since something got screwed up from when you went from your initial system build to where you are now

You mentioned CHOST: As I wrote I did not change CHOST (since the installation handbook warns from that...).
In fact I started from scratch and

1. installed the system according to the description in the 0.2005 installation handbook (stage 3 installation CD),
2. emerges some precompiled packages (X, xfce, kde etc., no basic things like gcc etc.) from CD
3. emerge --sync
4. emerge --update --deep world
5. emerges some other stuff (tetex, mc, firefox)

Where is the fault?

[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 http://bugs.gentoo.org/show_bug.cgi?id=23466 ), so maybe things have improved.

[qwertz]

Ah, well I have an idea what the issue is [...]

Please let me know...

[...] I've seen tons of people have issues with stage 3 installs

After reading the 0.2005 installation handbook I had the impression that a stage3 installation is the most common method (since the hole GRP infrastructure requires it).
So, actually, the opposite is true?

If so, I think, this should be noted in the installation handbook.

Is there anything I can do to improve this behaviour or is this all known and solutions are on the way?

[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. =/

[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

Code: Select all

root ~ # patch -p1 -i fix_libtool_files.sh.patch /sbin/fix_libtool_files.sh

3] grab fixlafiles.py from https://bugs.gentoo.org/attachment.cgi?id=44757 and put it in /usr/lib/portage/bin
4] make it executable

Code: Select all

root ~ # chmod a+x /usr/lib/portage/bin/fixlafiles.py

5] the last patch is a pain. it includes the header as context, which really sucks because every time the file gets modified by someone the header changes. so, you'll have to edit in the changes manually. luckily it's a very simple patch - 1 line to change, and 1 line and 1 block to add. you can see the patch here: https://bugs.gentoo.org/attachment.cgi?id=44758 just open /usr/lib/portage/pym/portage_contents.py in a text editor and make the changes.

that's it. fix_libtool_files.sh should have half a brain now. you don't need a version number anymore either, just run it. the --oldarch option is still there if you need it.

if something goes horribly wrong, you can undo the changes by remerging portage and copying the old fix_libtool_files.sh from /usr/portage/sys-devel/gcc/files/fix_libtool_files.sh to /sbin.

if something goes even more horribly wrong, i disclaim all responsibility.

[qwertz]

[...] 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 ...

I tried it (stage1) and I can confirm this. For about a week I didn't have ebuilds which didn't compile at all (however, some smaller missing dependencies which could be found quickly by looking at the error messages).

After all I probably found the "disturbing element". It seems that during gcc update (while installing from scratch with stage1/2) the file /etc/env.d/05gcc-i686-pc-linux-gnu ist left behind, containing the evil path (/usr/i386-pc-linux-gnu/gcc-bin/3.3.5). There is a (correct) 05gcc file, which is about 2 hours younger. So I guess the ebuild "forgot" to delete 05gcc-i686-pc-linux-gnu. On the "clean" system from stage1 install this doesn't matter, but maybe for the stage3 installation it did...

[yaneurabeya]

Hmmm.... could be.