# Probleme bei gcc 3.3.4 -> 3.3.5 (libstdc++...)

## tonmeister440

hi,

hatte ein ähnlches problem nach dem update heute. mein system lief zwar noch problemlos, konnte es auch neustarten, aber der updatevorgang ist bei imlib abgebrochen.

das lag wohl daran, das auch der gcc in einer neuen version (3.3.5) vorlag. dadurch hat sich in /usr/lib/gcc-libx/i686-pc-linux-gnu/ etwas geändert, die libs liegen jetzt in dem unterverzeichnis 3.3.5, was beim kompilieren von imlib nicht berücksichtigt wurde, die libs wurden noch immer in 3.3.4 gesucht, der ja nicht mehr vorhanden war. habe einfach einen symbolischen link ertstellt, der 3.3.4 heisst und auf das 3.3.5 zeigt. vielleicht hat es bei dir ja ähnliche hintergründe.

gruss tonmeister440

p.s. bison wurde noch vor dem gcc geupdated und das hat mein sys nicht beieinträchtigt.

mod edit: Aus vorsicht bei update: ed oder bison legt halbes system lahm abgespalten und sticky gemacht.

amne

mod edit2: Aus Faulheit noch (libstdc++...) hinzugefügt. --Earthwings

----------

## mortus

Nach dem Update von GCC 3.3.4 auf 3.3.5:

Lösung: 

```
 # fix_libtool_files.sh 3.3.4
```

cu

----------

## klemi

 *Quote:*   

> Nach dem Update von GCC 3.3.4 auf 3.3.5:
> 
> Lösung:
> 
> Code:
> ...

 [/list][/list][/code]

----------

## klemi

 *Quote:*   

> Nach dem Update von GCC 3.3.4 auf 3.3.5:
> 
> Lösung:
> 
> Code:
> ...

 

Kann mir mal jemand erklären, was die Code-zeile bewirkt?

Danke!

----------

## _hephaistos_

als root:

1) which fix_libtool_files.sh

2) less /sbin/fix_libtool_files.sh

ODER

1) fix_libtool_files.sh

dh: OHNE parameter aufrufen

hth,

ciao

----------

## bröggle

aber anscheinend funktioniert das ganze nicht so ganz wie gewollt, da durch das upgrade einige Dateien gelöscht werden aber nicht mehr ersetzt...

-siehe hier:

https://forums.gentoo.org/viewtopic.php?t=280055

:/

'never change a running system'

----------

## amne

Hier übrigens der Bugreport dazu. Bei mir ist der gcc 3.3.5 inzwischen von Hand maskiert bis das Problem gelöst ist.

----------

## tonmeister440

hi,

bei mir hat die lösung mit dem symbolischen link einwandfrei funktioniert, habe dannach den link weggenommen und den 

```
fix_libtool_files.sh 3.3.4
```

 ausgeführt. das hat auch geklappt. ich kann die fehler nicht nachvollziehen von denen ihr berichtet.

gruss tonmeister440

----------

## NightDragon

Hallo zusammen.

ich hatte auch selbes problem und habs auch ganz einfach, wie im oberen Posting beschrieben, gelöst.

Hatte das Problem hier auf allen gentoo-rechnern egal mit welchen einstellungen usw...

Und ja... nach der Aktion ging alles ohne Probleme.

evtl. gcc neu compilieren und nochmals fix_lib... usw... ausführen?

Könnte evtl. hier einiges lösen.

----------

## tonmeister440

hi,

ich hatte zwischenzeitlich ein anderes problem:

https://forums.gentoo.org/viewtopic.php?t=278649&sid=da41d4b6cd9084a0c1804dc18be97436

seitdem habe ich wieder diesen fehler gcc-3.3.4, obwohl ich ja 3.3.5 installiert habe. leider führt mich fix_libtool_files.sh 3.3.4 nicht zum gewünschten ergebnis, musste wieder den symb. link anlegen. ohne geht es nicht  :Sad: 

gruss tonmeister440

----------

## amne

Habs selbst noch nicht getestet, aber angeblich ist der Bug beim Upgrade jetzt gefixt: https://bugs.gentoo.org/show_bug.cgi?id=73435#c63

----------

## kamagurka

 *mortus wrote:*   

> Nach dem Update von GCC 3.3.4 auf 3.3.5:
> 
> Lösung: 
> 
> ```
> ...

 

yesss, danke!

----------

## paul revere

 *amne wrote:*   

> Hier übrigens der Bugreport dazu. Bei mir ist der gcc 3.3.5 inzwischen von Hand maskiert bis das Problem gelöst ist.

 

hallo das hab ich auch gemacht aber seit dem bekomm ich auch nur noch fehler beim mergen 

wenn sich das jemand mal ansehen könnte 

http://paste.phpfi.com/46708

hat jemand eine idee ??

----------

## slyght

bin mir nicht sicher, ob's am gcc liegt, aber bei mir bricht imlib auch beim updaten ab:

```

checking for gif_lib.h... no

configure: error: *** GIF header not found ***

```

Hab das mit dem fix_libtool_files.sh schon ausgeführt, aber bekomme den fehler immer noch

[edit]

kdelibs bricht auch ab:

```

libtool: link: `observer_stub.lo' is not a valid libtool object

make[4]: *** [libkdeinit_kio_uiserver.la] Error 1

make[4]: Leaving directory `/var/tmp/portage/kdelibs-3.3.2-r2/work/kdelibs-3.3.2/kio/misc'

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory `/var/tmp/portage/kdelibs-3.3.2-r2/work/kdelibs-3.3.2/kio/misc'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/var/tmp/portage/kdelibs-3.3.2-r2/work/kdelibs-3.3.2/kio'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/var/tmp/portage/kdelibs-3.3.2-r2/work/kdelibs-3.3.2'

make: *** [all] Error 2

```

----------

## cryptosteve

Ich hätte auch 'ne Fehlermeldung beizusteuern:

```
stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c    -O2 -march=athlon-tbird -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I/var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/gcc -I/var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/gcc/. -I/var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/gcc/config -I/var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/gcc/../include /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/gcc/genpreds.c -o genpreds.o

make[2]: *** Keine Regel vorhanden, um das Target »de_DE@euro«, 

  benötigt von »native«, zu erstellen.  Schluss.

make[2]: *** Warte auf noch nicht beendete Prozesse...

make[2]: Leaving directory `/var/tmp/portage/gcc-3.3.5-r1/work/build/gcc'

make[1]: *** [stage2_build] Fehler 2

make[1]: Leaving directory `/var/tmp/portage/gcc-3.3.5-r1/work/build/gcc'

make: *** [bootstrap-lean] Fehler 2

!!! ERROR: sys-devel/gcc-3.3.5-r1 failed.

!!! Function gcc_do_make, Line 1074, Exitcode 2

!!! emake failed with bootstrap-lean

!!! If you need support, post the topmost build error, NOT this status message.
```

----------

## Carlo

Um es mal zusammenzufassen:

1. Die fix_libtool_files.sh "Problematik" existiert schon eine ganze Weile länger als #73435 und beschränkt sich nicht auf gcc-3.3.4/5.

2. Wer gcc-3.3.x verwendet: emerge =binutils-2.15.90.0.3-r3 (und dabei bleiben). Das sollte einige der abstrus erscheinenden Fehler beseitigen. Alternativ kann man sich auch mit gcc-3.4.3 anfreunden.

3. gcc 3.3.x und gcc 3.4.x haben eine unterschiedliche C++ ABI. D.h. nach dem Update: revdep-rebuild --soname libstdc++.so.5 (dauert u.U. ein Weilchen) und nicht wieder zurück zu gcc 3.3.x.

----------

## slyght

 *Carlo wrote:*   

> Um es mal zusammenzufassen:
> 
> 2. Wer gcc-3.3.x verwendet: emerge =binutils-2.15.90.0.3-r3 (und dabei bleiben). Das sollte einige der abstrus erscheinenden Fehler beseitigen. Alternativ kann man sich auch mit gcc-3.4.3 anfreunden.
> 
> 

 

Diese binutils sind bei mir masked. Wie demaskier ich die denn?

Der Eintrag "sys-devel/binutils ~x86" in /etc/package.keywords hat nichts gebracht. Vielleicht weil schon spaetere Versionen existieren?

----------

## Carlo

Ups, sorry - binutils-2.15.90.0.1.1-r3 war gemeint. Hab' wohl nur auf die Revisionsnummer geschielt.

----------

## slyght

Ok, das hat leider nicht geholfen, deswegen wollte ich jetzt den gcc-3.4.3 testen.

Das revdep-rebuild bereitet mir allerdings Probleme:

1. 

```
Warning: Failed to resolve package order.

Will merge in "random" order!
```

2. Es findet einige Pakete nicht, die ich deshalb erstmal überspringen wollte. Hab also einige andere gemerged aber die sind beim nächsten Versuch wieder in der Liste.

Habe rm /root/.revdep-rebuild*.?_* aber durchgeführt und um binaries handelt es sich auch nicht... 

Was nun?!?

edit:

habe nun mit gcc-config den neuen gcc eingestellt und bekomme beim revdep-rebuild folgende meldung:

```
There are no dynamic links to libstdc++.co.5... All done.
```

Ist das ok, weil ich gcc-config vergessen habe, oder muss ich das revdep-rebuild vorher durchführen?

----------

## friedegott

 *slyght wrote:*   

> 
> 
> ```
> There are no dynamic links to libstdc++.co.5... All done.
> ```
> ...

 

es muss ja auch "libstdc++.so.5" heissen...

----------

## slyght

oh sorry, wie peinlich  :Embarassed: 

Also hab nun nochmal durchlaufen lassen, doch beim nächsten mal tauchen trotzdem wieder einige Pakete auf:

```
All prepared. Starting rebuild...

emerge --oneshot --nodeps  =app-arch/rar-3.4.0 =app-office/openoffice-bin-1.1.4 =dev-util/eclipse-sdk-3.0.1 =dev-util/eclipse-sdk-3.1_pre1 =kde-base/arts-1.2.3 =kde-base/kdebase-3.2.3-r1 =kde-base/kdegraphics-3.2.3 =kde-base/kdegraphics-3.3.2-r2 =kde-base/kdelibs-3.2.3-r2 =kde-base/kdelibs-3.3.2-r2 =kde-base/kdesdk-3.2.3 =kde-base/kdewebdev-3.2.3 =media-gfx/digikam-0.6.2 =media-video/ati-drivers-8.8.25-r1 =net-im/skype-0.93.0.3-r3 =net-www/opera-7.54-r1 
```

Openoffice und Opera sind normal, weil bin aber der Rest?

Mich wundert vor allem, dass zwei kdebase/kdelib versionen drin sind. Sollte ich die ältere vllt deinstallieren?

Sollte mich das stören, dass dort noch einige Pakete sind, obwohl sie schon einmal neu gebaut wurden?

----------

## Carlo

 *slyght wrote:*   

> Mich wundert vor allem, dass zwei kdebase/kdelib versionen drin sind. Sollte ich die ältere vllt deinstallieren?

 

Entweder das oder Du solltest neuere Revisionen einiger Pakete einspielen, in denen mehrere Sicherheitslücken behoben sind. Zum Thema Slots haben wir wunderbare Dokumentation.

----------

## sirro

Anmerkung: fix_libtool_files.sh aendert natuerlich die Zugriffszeit der Dateien. Beim deinstallieren gibt das ne ganze Menge !mtime fuer die geaenderten libs...

Wer ein sauberes System behalten will, der sollte da nach jedem Loeschen einen Blick auf den Output werfen und die !mtimes von Hand rauswerfen.

Gibts da einen anderen Loesungsansatz fuer?

----------

## Carlo

 *sirro wrote:*   

> Gibts da einen anderen Loesungsansatz fuer?

 

Kurzfristig: Schreib Dir (uns  :Wink: ) ein Skript, das /var/db/pkg/*/*/CONTENTS mit dem System abgleicht!

Mittelfristig: siehe Bug 71265

----------

## c07

Einen ganz einfachen Vergleich macht dieses Skript:

```
#! /bin/bash

for contents in /var/db/pkg/*/*/CONTENTS; do

  cat $contents | (

    while read type file md5 time; do

      [[ $type == obj ]] || continue

      [[ -f $file && $time == `stat -c%Y $file` ]] &&

        echo "$md5  $file" | md5sum -c --status && continue

      echo $file

      done

  )

  done
```

Gibt fehlende oder veränderte Dateien aus, scheitert aber an Dateien mit Leerzeichen im Namen. Ohne den MD5-Vergleich wär es wahrscheinlich merkbar schneller.

----------

## Linuxpeter

Ich hab es auch mit gcc-3.3.5-r1 probiert - und hab dann letztendlich auf gcc-3.4.x geupdated und keine Probleme damit.

----------

## NightDragon

Warum verwendet ihr jetzt alle 3.4.x ? *g* Hab ich da was versäumt? Ist die Version jetzt als Stabil gekennzeichnet?

Gibts irgendwas schlimmes in der 3.3.5? Was die 3.4.x nicht mehr hat?

----------

## amne

Auf amd64 ist der 3.4.x sowieso stabil und auf x86 gibts einige Leute, die 3.4.x verwenden weil er für den Pentium-m optimieren kann.

----------

## c07

 *NightDragon wrote:*   

> Gibts irgendwas schlimmes in der 3.3.5? Was die 3.4.x nicht mehr hat?

 

Mir ist bei der Durchsicht des Quelltexts aufgefallen, dass bei 3.3.5 Bugfixes fehlen, die eigentlich schon seit ewiger Zeit gefixt sind (suboptimale Athlon-Optimierungen; im November 2002 im CVS korrigiert). Da kann ich dann auch ein paar neue Bugs in 3.4 in Kauf nehmen (wobei das natürlich eher die kritischeren sind).

----------

## NightDragon

Aha... Thx für die Infos Jungs. Interessant.

----------

## talktest

habe dieses Prob bisher immer pragmatisch gelöst ...

Aktuell:

#ln -s /usr/lib/[...]/3.3.5 /usr/lib/[...]/3.3.4

PS: das mit 

#fix_libtool_files.sh 3.3.4

#env-update

#source /etc/profile

brachte beim mir spez. bei

#emerge jpeg

nichts.

----------

## NightDragon

Versuchs mal ohne versionsangabe!

----------

## hasenfreser

Hey Jungs, das geht auch einfacher 

https://forums.gentoo.org/viewtopic-p-2108472.html#2108472

----------

## amne

Vorausgesetzt es sind nur giflib und imlib betroffen.

----------

## firefly

das Problem damit hatte ich auch nach update auf 3.3.5 und fix_libtool_files.sh 3.3.4 wurde das problem nicht behoben.

Nur nachdem ich den gcc 1 bis 2 mal re-emergt hatte war das problem auch ohne symlink weg  :Smile: 

Denn das problem war nicht nur bei emergen von Programmen aufgetreten sondern auch beim einfachsten 

"Hello World" - Programm mit dem g++.

Und da glaub ich das es zum einen teil an den *.la dateien und zum anderen teil an der nicht richtig gesetzten LDPATH variable für den gcc liegt.(wahrscheinlich wurde die datei /etc/env.d/05gcc nach dem update nicht angepasst)

Deshalb sollte jeder mal schauen, der das Problem hat, ob in der LDPATH variable nach dem update noch der alte pfad (auch nach einem env-update && source /etc/profile bzw. einem neuanmelden) drinn steht oder schon der neue.

beim update von 3.3.4 nach 3.3.5 sollte der Pfad nicht mehr

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4

sondern

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 

lautet.

----------

## bröggle

ähm:

bash-2.05b$ echo $L

$LADSPA_PATH         $LESSOPEN            $LOGNAME

$LANGUAGE            $LIBGL_DRIVERS_PATH  $LS_COLORS

$LC_LANG             $LINENO

$LESS                $LINES

bash-2.05b$ echo $L

?LDPATH?

----------

## firefly

die LDPATH varible ist keine shell variable ansich, die ständig verfügbar ist.

Die wird nur zur compile zeit für den compiler erzeugt.

Die variable wird, wie ich schon sagte, in der datei /etc/env.d/05gcc festgelegt.

desweiterne kann man sich noch mit

```
$ gcc -print-search-dirs
```

 anzeigen lassen, in welchen verzeichnissen der compiler nach libs sucht.

Und ich würde sagen, das der fehler, der auch nach einem fix_libtool_files.sh noch besteht, daran liegt,

das wahrscheinlich die LDPATH variable in /etc/env.d/05gcc falsch gesetzt ist.

Oder das der suchpfad, für die vom gcc mitgelieferten libs, irgentwie im gcc selber fest einkompiliert worden sind.

Deshalb hat sich wohl bei mir das Problem behoben, nachdem ich den gcc nach dem update noch einmal reemergt hatte.

Es könnte vieleicht auch helfen mit gcc-config die datei /etc/env.d/05gcc nochmal zu erzeugen, wenn die templates in /etc/env.d/gcc stimmen. (was mit der neusten version von gcc-config passen sollte)

Desweiteren ist das fix_libtool_files.sh script an sich nicht so toll da, wie ich schon in diesem thread gelesen habe, diese script die mtime verändert. Dadurch werden die Dateien, die durch dieses script veränderten worden sind, später bei einem unmerge vorgang des paketes mit einem mtime "fehler" nicht mit gelöscht.

gruß

firefly

----------

## peanut

Hm, jetzt habe ich mich schon kräftig an diesem Thread entlanggehangelt, aber irgendwie kriege ichs noch nicht gebacken. Beim emerge von sane-backends bricht gcc kurz vor Schluß mit folgender Meldung ab: 

```
../tools/sane-desc: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libgcc_s.so.1: version `GCC_3.3' not found (required by //usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libstdc++.so.5)
```

So wie ich das verstehe, versucht er, die libgcc Version 3.2.3 zu finden und zu linken, was dann aber nicht klappt. gcc-3.3.5-r1 ist aber sehr wohl installiert: 

```
tux root # gcc-config -l

[1] i686-pc-linux-gnu-3.2.3

[2] i686-pc-linux-gnu-3.3.4

[3] i686-pc-linux-gnu-3.3.5 *

[4] i686-pc-linux-gnu-3.3.5-hardened

[5] i686-pc-linux-gnu-3.3.5-hardenednopie

[6] i686-pc-linux-gnu-3.3.5-hardenednossp

```

fix_libtool_files.sh 3.3.4 ist ebenfalls schon längst passiert. env-update und source /etc/profile auch. In der /etc/env.d/05gcc steht u. a.

```
#LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4"

LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4"

```

Der obere LDPATH ist der ursprüngliche, den ich auskommentiert hatte. Ich hoffte, gcc durch die alleinige Angabe der Version 3.3.4 dazu überreden zu können, die libs der Version 3.3.4 zu verwenden.

Wie kann ich gcc dazu bringen, die Version 3.2.3 zu ignorieren? Ich denke, das wird wohl der Fehler sein. 

Ich traue mich nur nicht, den gcc zu unmergen. Womit sollte ich danach noch etwas installieren...?

Gruß,

    peanut

----------

## c07

Ich würd mal 

```
fix_libtool_files.sh 3.2.3
```

 probiern.

gcc 3.2.3 zu unmergen sollte ziemlich sicher sein, wenn du keine spezielle Verwendung dafür hast. Du hast ja noch zwei andere.

----------

## firefly

ähm wiso hast du den LDPATH auf den gcc version 3.3.4 gesetzt und nicht 3.3.5 wie per gcc-config ausgewählt ??

gruß

firefly

----------

## peanut

Weil ich das als Lösung des Problems so verstanden hatte: emerge gcc-3.3.5(-r1) gibt Probleme. Mit fix_libtool_files 3.3.4 gibts keine Probleme. Und das, obwohl man gcc-3.3.5 verwendet. Oder hab ich da was nicht kapiert?

Achja, den gcc-3.2.3 hab ich scheinbar gar nicht mehr drin, ich habe in make.conf mal AUTOCLEAN=YES gesetzt. Inzwischen nicht mehr, weil ich gcc-3.3.4 wieder emerged habe.

```

root # emerge --unmerge gcc-3.2.3

--- Couldn't find gcc-3.2.3 to unmerge.

>>> unmerge: No packages selected for removal.

```

Gruß,

    peanut

----------

## firefly

@peanut: probier mal folgendes :

remerge den gcc-3.3.5 und eventuell libtool neu dann sollte das Problem weg sein.

(war bei mir so)

gruß

firefly

----------

## Earthwings

Abgeheftet.

----------

## stillner

Genau bei jpeg hatte ich auch die Probleme - bei mir hat geholfen, zuerst noch mal

# emerge libtool

auszuführen, und dann erst

# fix_libtool_files.sh 3.3.4

 *talktest wrote:*   

> habe dieses Prob bisher immer pragmatisch gelöst ...
> 
> Aktuell:
> 
> #ln -s /usr/lib/[...]/3.3.5 /usr/lib/[...]/3.3.4
> ...

 

----------

