# 2006.1 gcc 4.1

## Bithammer

https://forums.gentoo.org/viewtopic-t-493714.html

Ich bin mir nicht sicher - aber ich vermute das es zu diesem thema evtl doch einige fragen geben wird.

Ist der alte GCC damit dann obsolete && unsupported ?

http://www.gentoo.org/doc/en/gcc-upgrading.xml

letztendlich bedeutet das man sein ganzes system neu übersetzen sollte wenn man auf den neuen compiler switcht.  Ist das dann automatisch ein parallel betrieb des compilers ? Oder wird 3.3.6 dann geunmergt ?

----------

## Bithammer

http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

Was ist mit den neuen USE flags mit denen man den Compiler übersetzen kann ? Wenn ich den GCC mit libmudflap support baue - kann ich den dann immer benutzen oder muss ich dann noch weitere use flags setzen um ihn ein /auszuschalten ? Ein programm zu übersetzen mit libmudflap dauert ja wohl auf jedenfall etwas länger weil zustäzliche checks gemacht werden.

----------

## amne

 *Bithammer wrote:*   

> https://forums.gentoo.org/viewtopic-t-493714.html
> 
> Ich bin mir nicht sicher - aber ich vermute das es zu diesem thema evtl doch einige fragen geben wird.
> 
> 

 

Stimmt, und deswegen ist der Thread auch offen.  :Wink: 

 *Bithammer wrote:*   

> 
> 
> Ist der alte GCC damit dann obsolete && unsupported ?

 

Jein. Es zwingt dich keiner, innerhalb der nächsten 24 Stunden umzusteigen, jedoch ist (glaube ich) gcc 3.4 von Seiten der gcc-Entwickler nicht mehr offiziell unterstützt. Langfristig ist also der Wechsel auf gcc 4.1 allein deshalb schon sehr empfehlenswert.

 *Bithammer wrote:*   

> http://www.gentoo.org/doc/en/gcc-upgrading.xml
> 
> letztendlich bedeutet das man sein ganzes system neu übersetzen sollte wenn man auf den neuen compiler switcht.  Ist das dann automatisch ein parallel betrieb des compilers ? Oder wird 3.3.6 dann geunmergt ?

 

Automatisch passiert gar nichts, gcc 3.3, 3.4 und 4.1 leben in verschiedenen Slots und können daher parallel installiert sein - wie in der Anleitung beschrieben liegt es am Admin auf gcc 4.1 umzustellen (mit gcc-config), ebenso wird der alte erst dann deinstalliert, wenn der Admin es veranlasst.

----------

## hurra

Gibts irgendwo nen Guide für die Umstellung von 3.4.x auf 4.1.x ?

----------

## psyqil

http://www.gentoo.org/doc/de/gcc-upgrading.xml

Nen dicken Typo in der Überschrift... na super, amne!   :Twisted Evil: 

----------

## Bithammer

Hmmm bin schon dabei, wobei ich es natürlich merkwürdig finde das man glibc && gcc gleich 2 mal übersetzt laut anleitung. Erstmal übersetzt man beide mit dem alten compilter und danach durch emerge -e gleich nochmal weil damit der tree neu gebildet wird. Man übersetzt dann gcc 4.1 sourcecode mit gcc 4.1. Würde sich der "neue" GCC dann unterscheiden von der funktionalität wenn er sich selbst übersetzt ? 

Das mit dem Multislot habe ich mittlerweile nachgelesen, der GCC ist halt schon ein sehr Zentrales element und da habe ich halt mal vorsichtshalber nachgefragt was denn da so an konsequenzen zu erwarten sind.

Edit:

Es kommt sogar noch schlimmer - da einige pakte in der World favourites file und System favourites file vorhanden sind werden die auch noch doppelt gemergt wie z.b. ncurses, zlib oO...

Naja bevor ich mir irgendwelche abhängigkeiten probleme einhole dann halt von mir aus alles 2x durchcomplilen. Aber so richtig schön finde ich die upgrade anleitung nicht. 

Vielleicht ist es ja auch beabsichtigt das einige pakete unter beiden favourites abgelegt sind - auch wenns für mich so jetzt erstmal keinen sinn macht. Evtl hätte es dann gereicht einfach nur emerge - world zu machen ? Wenn World = System + Rest ist ?

----------

## ChrisJumper

 *Bithammer wrote:*   

>  Man übersetzt dann gcc 4.1 sourcecode mit gcc 4.1. Würde sich der "neue" GCC dann unterscheiden von der funktionalität wenn er sich selbst übersetzt ? 

 

Ja das ist ganz normal mit Compilern. Stell dir mal vor: der "erste" musste sich sogar an den eigenen Haaren aus dem Sumpf ziehen :)

Die Funktionen unterscheiden sich wohl eher nicht. Aber wenn er dann effektiver und schneller arbeitet, ist das doch auch schon eine menge Wert.

----------

## amne

 *psyqil wrote:*   

> http://www.gentoo.org/doc/de/gcc-upgrading.xml
> 
> Nen dicken Typo in der Überschrift... na super, amne!  

 

Hehe, ist nicht meine Schuld, mit der deutschen Version hab ich nix zu tun.  :Wink: 

Ich würde übrigens die englische Version empfehlen, in der deutschen sind die letzten Änderungen noch nicht verfügbar.

edit: Neue, korrigierte Version der deutschen Anleitung mit den letzten Änderungen ist in wenigen Minuten ebenfalls online.  :Very Happy: 

----------

## xraver

 *hurra wrote:*   

> Gibts irgendwo nen Guide für die Umstellung von 3.4.x auf 4.1.x ?

 

habs mal von http://www.gentoo.org/doc/en/gcc-upgrading.xml gepastet;

```

# emerge -uav gcc

(Please substitute "i686-pc-linux-gnu-4.1.1" with the GCC

version and CHOST settings you've upgraded to:)

# gcc-config i686-pc-linux-gnu-4.1.1

# source /etc/profile

If you upgraded from gcc 3 to 4 (e.g. from 3.4.6 to 4.1.1 in this

example) you will have to run fix_libtool_files.sh manually

# fix_libtool_files.sh 3.4.6

(Rebuilding libtool)

# emerge --oneshot -av libtool
```

Rebuilding system

```
# emerge -eav system

# emerge -eav world
```

Und den alten gcc deinstallen;

```
emerge -aC =sys-devel/gcc-3.4*
```

----------

## franzf

Für ein World-remerge (und andere, längere emerges) empfiehlt sich das geniale Script mymerge. Einfach Forensuche anwerfen, findet man sicher  :Wink: 

Grüße

Franz

----------

## xraver

 *franzf wrote:*   

> Für ein World-remerge (und andere, längere emerges) empfiehlt sich das geniale Script mymerge. Einfach Forensuche anwerfen, findet man sicher 
> 
> Grüße
> 
> Franz

 

Hab aber gerade keine Lust zu suchen. Wenn du das script schon anpreisen tust - dann sag wenigstens auch warum und was du daran so toll findest. "geniale" Scripte find ich überall - glaube eins heisst Vista   :Wink: 

----------

## Bithammer

http://penguinslair.dyndns.org/forums/viewtopic.php?t=40&start=0&postdays=0&postorder=asc

danke Franz, genau das richtige für solche momente.

Sollte an für sich direkt mit in die Anleitung gepostet werden ^^.

mod edit: url um unnötige search-id gekürzt wg. Zeilenumbruch.

amne

----------

## franzf

 *xraver wrote:*   

>  *franzf wrote:*   Für ein World-remerge (und andere, längere emerges) empfiehlt sich das geniale Script mymerge. Einfach Forensuche anwerfen, findet man sicher 
> 
> Grüße
> 
> Franz 
> ...

 

Ich glaub du hast da was falsch verstanden! Vista ist kein Script, sondern ein Virus, der speziell für Windows-Only-PCs geschrieben wurde...

Der Link zu dem Mymerge-Script wurde schon gepostet. Das Script macht nix anderes als nach Fehlern bei dem Merge eines Pakets weiter zu machen und am Ende des Vorgangs (sei es weil die Paketliste durch ist oder der User mittels [strg]+C abbricht, oder ...) die Liste der fehlgeschlagenen Pakete auszuspucken.

Ist deshalb genial weil man nicht ständig vor dem PC hocken muss und sich alle nicht funktionierenden Pakete, was ja immer wieder mal passiert, mitnotieren muss oder mühsam die emerge.log durchforten braucht.

Aber das hast du sicherlich eh grad schon rausgefunden  :Wink: 

Grüße

Franz

----------

## xraver

@franzf

Ok, thx - mymerge koennte selbst mir gefallen.

----------

## BuLLy

Welche von den neuen USE-Flags für den neuen GCC müssen denn unbedingt aktiviert werden und welche sind nützlich?

gruß

BuLLy

----------

## Bithammer

 *BuLLy wrote:*   

> Welche von den neuen USE-Flags für den neuen GCC müssen denn unbedingt aktiviert werden und welche sind nützlich?
> 
> gruß
> 
> BuLLy

 

Würde mich auch brennend intressieren - wie z.b. das +mudflap flag das die libmudflap als ergänzung installiert. Prüft das nur auf Array misses und meldet fehler ODER korrigiert es diese auch gleich. Ich habe da bisher auch nur wenig drüber gefunden. Objektives C++ als support einzuschalten hat auf jedenfall beim emerge -e system emerge -e world nicht geschadedt vielleicht gibts ja in zukunft ein paar pakete die objektives C++ benutzen und dann ist mein compiler zumindest ready dafür. 

Ansonsten sind sicherlich die ganzen performance junkies sicherlich intressiert was es noch für optimierungen gibt oder ob sich da nix getan hat.

----------

## SvenFischer

Von http://www.gentoo.org/doc/de/gcc-upgrading.xml#first-install

 *Quote:*   

> 
> 
> Ab diesem Zeitpunkt ist es sicher, die alte GCC-Version zu löschen. Bitte ersetzen Sie IHRE-NEUE-GCC-VERSION mit der Version auf die Sie aktualisiert haben:
> 
> Befehlsauflistung 4.5: Aufräumen
> ...

 

Das ist doch falsch, oder? Warum sollte man die neueste Version deinstallieren / Widerspruch!?

----------

## Finswimmer

< bedeutet, dass alle früheren Versionen gelöscht werden

----------

## toralf

 *ChrisJumper wrote:*   

> Ja das ist ganz normal mit Compilern. Stell dir mal vor: der "erste" musste sich sogar an den eigenen Haaren aus dem Sumpf ziehen 

  :Smile: 

----------

## NightDragon

Hallöle!

Sagt mal Leute, habt ihr auch soviele Probleme mit dem gcc 4.1.1 und dem neukompilieren des Systems?

(lt. des Howtows usw... mit libfix, emerge system usw...)

ncurses wollte keine LDFlags, gnome-libs will gar nicht (irgendwas mit libpng12.so.1 usw... passt nicht, wieder mal eine refernez nicht gefunden, aber linpng lässt sich Problemlos komplieren, genau wie imlib von daher keine Ahnuign was da los ist).

usw...

Wenn das bei jedem so losgeht, dann wird Gentoo nicht mehr viele Leute haben *g*.

Ich bin sowieso stur, bis ich weg bin von Gentoo, muss eine Neuinstallation fast unmöglich sein.

----------

## Finswimmer

Nee. Hier alles super  :Smile: 

Hab grad meinen Server neu kompiliert...

Und vor längerer Zeit auf meinem Hauptrechner.

Hast du "emerge -1 libtool" gemacht?

revdep-rebuild vor emerge -e system?

Tobi

----------

## NightDragon

Revdep lies ich eben durchlaufen. Ohne Probleme oder Fehler.

Vorher hatte ich nioch mit dem ebuild encodings probleme "gzopen, sysmbol lookup error"..

----------

## Finswimmer

Dann zeig mal die Fehler, die entstehen, wenn du emerge -e system machst.

----------

## NightDragon

Jope mach ich dann.

Ich habe gerade im Upgrade-Kit gelesen das man die Kernel auch neu übersetzen soll, zwecks externen modulen.

Wenn ich dann wieder von Vorne beginne, werd ich hier (sofern KDE dann noch mag) alle Infos posten.

Verwendet ihr LDFLAGS?

----------

## tuxian

 *Finswimmer wrote:*   

> Nee. Hier alles super 
> 
> revdep-rebuild vor emerge -e system?
> 
> Tobi

 

Ist revdep-rebuild wirklich nötig? Steht ja nicht in der Anleitung?

Kann ich das auch ganz zum Schluss (nachdem der alte gcc gelöscht wurde) machen?

----------

## Finswimmer

Nee. Eigentlich ist es unwichtig, denn emerge -e system baut das System komplett neu.

Nur, wenn etwas nicht geht, dann sollte man revdep machen, so wie in dem Fall, auf den ich geantwortet habe.

Tobi

----------

## NightDragon

Rele...

So ich konnte das Problem ausfindig machen.

zlib mag keine LDFLAGS. Aus Sicherheitsgründen baue ich jetzt das System + Welt ( 1,5GB, 1026 ebuilds) ohne neu.

Schade, denn auf das --as-needed Flag wär ich schon scharf gewesen. Solls doch speed bringen und RAM sparen.

Wie dem sei.... 

Irgendwann wird das problem auch behoben sein, und dann wird eben nochmals neugebaut.

Thx für die Hilfe Leute...

----------

## franzf

wegen revdep-rebuild:

Das war bei mir lustig. Hab mittels mymerge das ganze Universum neu gebaut. Die fehlgeschlagenen Pakete gefixed. Dann einfach mal revdep-rebuild angeschmissen -> der hat tatsächlich nach dem gcc-3.4.5 verlangt oO (und sonst nix...). Nachdem eigentlich alles mit gcc-4.1.1 erfolgreich neu gebaut wurde.

Naja, is wurscht, für was hat man denn noch 10GB auf root frei  :Very Happy: 

Grüßle

Franz

----------

## ConiKost

Ich habe mein gesammtes System mit LDFLAGS="-Wl,-O1" gebaut ...

Rennt ohne Probleme  :Smile: 

----------

## flammenflitzer

Bringt es für die Systemperformance etwas? Anfangs wurde der neue Compiler ja ziemlich verrissen.

----------

## Thargor

Was sind eigentlich die tollen neuen Features des gcc 4.1?

----------

## Tyler_Durden

 *NightDragon wrote:*   

> Rele...
> 
> So ich konnte das Problem ausfindig machen.
> 
> zlib mag keine LDFLAGS. Aus Sicherheitsgründen baue ich jetzt das System + Welt ( 1,5GB, 1026 ebuilds) ohne neu.
> ...

 

Mit "--as-needed" habe ich mich 'ne ganze Weile herumgeschlagen, habe mir damit aber zu viele Probleme eingehandelt.

Von meinen ~1600 Paketen kommen ca. 40 damit nicht klar, entweder beim configure-script (z.B. checks gegen GTK+-1.x),

oder es kann genau solche Linker-Probleme geben, wie Du's mit imlib und libpng beschrieben hast. Pakete, die damit sicher

laufen, setzen das Flag schon selbst.

Ich benutze nur noch: 

```
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--hash-style=both"
```

 ...und das läuft super.

----------

## TheCurse

zlib mag auch kein --ftee-vectorize, nur um das mal kurz anzumerken. Baut zwar, aber diverse Programme (firefox, azureus etc.) starten nicht mehr. Mit den LDFLAGS und zlib habe ich allerdings keine Probleme.

----------

## a.forlorn

Eigentlich kann man entweder 

(a) revdep-rebuild

oder

(b) emerge -e system / world

machen. Da ich an meinem Rechner arbeiten muss und ein emerge -e meiner Meinung nach nur spielerei ist, nehm ich nur revdep-rebuild. Ganze drei Pakete waren notwendig.  :Razz: 

----------

## TheCurse

Man sollte schon seinen toolchain neu bauen, sonst könnte man doch ein paar Probleme bekommen.

----------

## a.forlorn

Das ist klar, nur emerge -e system + world dauert Ewigkeiten ohne irgendwie produktiv etwas zu bringen (wenn man seine flags nicht ändert).

----------

## flammenflitzer

 *Thargor wrote:*   

> Was sind eigentlich die tollen neuen Features des gcc 4.1?

 

Bei Golem:GCC 4.1 mit neuen Optimierungen und Objective C++

Der GNU Compiler wartet in der Version 4.1 mit interprozeduralen Optimierungen und Unterstützung für Apples Objective C++ auf - auch die Java-Bibliothek wurde weiter ausgebaut.

Die von AMD empohlenen Compileroptionen (generic Performance Switches)  (-O3 -ffast-math -funroll-all-loops -ftracer -funswitch-loops -ftree-vectorize) bei Version 3.... (-O3 -ffast-math -funroll-all-loops -fpeel-loops -ftracer -funswitch-loops -funit-at-a-time)

Die entscheidende Frage ist: Was bringt es? Bin ich nur up-to-date, oder bekomme ich einen Performance-Schub.

----------

## TheSmallOne

 *TheCurse wrote:*   

> Man sollte schon seinen toolchain neu bauen, sonst könnte man doch ein paar Probleme bekommen.

 

Hm, wieso gibt es eigentlich nicht sowas wie "emerge toolchain", so als virtuelles pendant zu "world" oder "system"?

Aber irgendwie habe ich ein grundsätzliches Verständnissproblem: Wieso erfordert ein Wechsel des Compilers eine neukompilation bestimmter Programme?

Die Aufgabe des Compilers ist es doch, aus Sourcecode ausführbaren Maschinencode zu generieren. Die entstehenden Programme sind dabei dann von bestimmten Bibliotheken abhängig, deshalb ist es auch einleuchtend, dass ein Wechsel der Bibliotheken eine neukompilation erfordern kann, aber der Compiler?   :Question: 

Wenn die Programme erstmal fertig sind haben sie doch mit dem Compiler gar nichts mehr am Hut, also kann es ihnen doch egal sein, welcher Compiler installiert ist. Und wenn ich nun gar keinen Compiler mehr auf dem System hätte?

----------

## NightDragon

Also die ganze Toolchain und System sind neu übersetzt... und die Welt ist gerade drann  :Smile: 

(Ebuild 194 von 1067) :Smile: 

Soweit läufts (ohne LDFLAGS) gut.

----------

## Klaus Meier

Also ich weiß nicht, welche Cflags wirklich was bringen. Aber bei meinem 32-bit System auf einem Athlon64 machen viele Anwendungen mit -O3 Ärger. entweder emerge geht erst gar nicht durch oder sie kacken hinterher ab. Mit -O2 -fomit-frame-pointer hatte ich bislang noch nie Probleme.

Und da wir auch gerade bei Performance sind, bringt prelink eigentlich was? Probiere damit gerade rum und muß feststellen, die Binaries werden ca doppelt so groß. Da dauert das Laden doch schon ewig.

----------

## tuxian

Sind durch den Wechsel von 2006.0 auf 2006.1 einige default USE-Flags nicht mehr ausgewählt?

Ich musste nämlich bis jetzt "X" und "png" in die make.conf aufnehmen um einige Pakete kompilieren zu können.

----------

## Tranalogic1987

Grüß euch Leute, bin gerade am Server und der Workstation das System Neu kompilieren nur eine Frage hab ich, gibts ne Möglichkeit das er bei world und system nicht die Pakete downgradet sondern die gleiche installierte Version neu kompiliert? Hab nämlich auch ein paar ~ARCH's installiert zb. kde 3.5.4 usw. 

Merci und schönen Abend noch.

----------

## tuxian

Habe auch kde 3.5.4 installiert und da die Pakete korrekt in die packages.keywords eingetragen sind gab es auch keine Probleme.

----------

## Mr.Big

 *tuxian wrote:*   

> Sind durch den Wechsel von 2006.0 auf 2006.1 einige default USE-Flags nicht mehr ausgewählt?
> 
> Ich musste nämlich bis jetzt "X" und "png" in die make.conf aufnehmen um einige Pakete kompilieren zu können.

 

scheint so, hatte hier ähnliche Probleme.

J.

----------

## dek

 *Klaus Meier wrote:*   

> Und da wir auch gerade bei Performance sind, bringt prelink eigentlich was? Probiere damit gerade rum und muß feststellen, die Binaries werden ca doppelt so groß. Da dauert das Laden doch schon ewig.

 

Ganz im Gegenteil, die Programme starten schneller. Bei der Performance hingegen ändert sich nichts.

Gentoo Linux Prelink Einführung

----------

## SinoTech

 *TheSmallOne wrote:*   

> 
> 
> [...]
> 
> Aber irgendwie habe ich ein grundsätzliches Verständnissproblem: Wieso erfordert ein Wechsel des Compilers eine neukompilation bestimmter Programme?
> ...

 

Viele der Bibliotheken, von denen das entstandene Programm abhängt, gehören zum Compiler. Updatest du den Compiler und möchtest den alten entfernen (Was ja meistens so ist), müssen die Programme gegen die Bibliotheken des neuen Compilers gelinkt werden.

Mfg

Sino

----------

## slick

```
!!! ERROR: app-emulation/qemu-user-0.8.2 failed.

Call stack:

  ebuild.sh, line 1555:   Called dyn_setup

  ebuild.sh, line 668:   Called pkg_setup

  qemu-user-0.8.2.ebuild, line 31:   Called die

!!! Qemu must build with GCC 3

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

```
 * qemu requires gcc-3 in order to build and work correctly

 * please compile it with gcc-3

!!! ERROR: app-emulation/qemu-softmmu-0.8.2-r1 failed.

Call stack:

  ebuild.sh, line 1555:   Called dyn_setup

  ebuild.sh, line 668:   Called pkg_setup

  qemu-softmmu-0.8.2-r1.ebuild, line 36:   Called die

!!! gcc 4 cannot build qemu

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

Mist... und das mitten im emerge -e world. Was mach ich jetzt am besten? Mit gcc-3* kompilieren oder die ebuilds editieren?  :Sad: 

----------

## tuxian

Ich würde mal das ebuild editieren und es mit gcc-4.1.1 probieren.

Ich kann jetzt leider nochmals ein "emerge -uD --newuse world" laufen lassen.

Mit /usr/portage/profiles/default-linux/x86/2006.1/ wird anscheinend das Server-Profil ausgewählt und daher wurden für alle Pakete bei "emerge -e world" fast keine default-useflags aktiviert und ich hatte jede Menge Probleme.

/etc/make.profile zeigt jetzt auf /usr/portage/profiles/default-linux/x86/2006.1/desktop und es läuft grade ein "emerge -e world".

Frage: Steht irgendwo dass mit /usr/portage/profiles/default-linux/x86/2006.1/ automatisch /usr/portage/profiles/default-linux/x86/2006.1/server ausgewählt ist?

Ist irgendwo der unterschied zw. server und desktop beschrieben?

Mit dem Problem bin ich sicher nicht alleine, schade dass das nirgends gestanden ist.

----------

## achimh

hallo

hab jetzt auch von gcc 3.3.4 auf 4.1.1 umgestellt und bei emerge -eav world hat er ma auch bei einem paket abgebrochen

hätt dann nur mehr 70 pakete oder so gehabt; hab jetzt den gcc 3.3.4 heruntergelöscht

```
emerge -eav system
```

 hat ohne probleme bei mir geklappt

ich werd das ganze jetzt nicht mehr anfangen, da das schon sehr mühsam ist  :Smile: 

hoffe und glaube das macht nichts, 

```
revdep-rebuild -p
```

 zeigte keinerlei broken packages

----------

## nikaya

 *SinoTech wrote:*   

> 
> 
> Viele der Bibliotheken, von denen das entstandene Programm abhängt, gehören zum Compiler. Updatest du den Compiler und möchtest den alten entfernen (Was ja meistens so ist), müssen die Programme gegen die Bibliotheken des neuen Compilers gelinkt werden.
> 
> 

 

Ich versuche diese Geschichte auch gerade zu verstehen.

Wenn ich also den Compiler komplett deinstallieren würde könnte ich nicht nur keine neuen Programme kompilieren,sondern auch die vorhandenen wären unbrauchbar da evtl. Bibliotheken fehlen würden?

Wie machen das dann Binär-Distris die ja in der Regel erstmal keinen Compiler mitinstallieren?

----------

## nikaya

 *tuxian wrote:*   

> 
> 
> Frage: Steht irgendwo dass mit /usr/portage/profiles/default-linux/x86/2006.1/ automatisch /usr/portage/profiles/default-linux/x86/2006.1/server ausgewählt ist?
> 
> Ist irgendwo der unterschied zw. server und desktop beschrieben?
> ...

 

In "/usr/portage/profiles/default-linux/x86/2006.1" ist noch eine Datei "make.defaults" welche vom /etc/make.profiles-Symlink verwendet wird.

Genauso ist in "desktop" und "server" eine "make.defaults" Datei.Und in diesen Dateien sind halt die Default USE-Flags aufgeführt.

Bei mir sieht es so aus:

/usr/portage/profiles/default-linux/x86/2006.1

```
USE="cups gdbm gpm libg++ nptl nptlonly ppds udev unicode"
```

/usr/portage/profiles/default-linux/x86/2006.1/desktop

```
USE="alsa arts avi cairo cdr dbus dvd dvdr eds emboss encode esd fam firefox gif gnome gpm gstreamer gtk hal jpeg kde ldap mad mikmod mp3 mpeg ogg opengl oss pdflib png qt3 qt4 quicktime sdl spell truetype vorbis win32codecs unicode X xml xv"
```

/usr/portage/profiles/default-linux/x86/2006.1/server

```
USE="apache2 ldap mailwrapper mysql snmp truetype xml"
```

----------

## tuxian

Ja stimmt, nun gibt es also drei verschiedene make.profile-Dateien.

Das Problem ist eher dass die /usr/portage/profiles/default-linux/x86/2006.1/make.defaults sehr abgespeckt wurde und nicht dass es zusätzlich eine make.defaults in den Verzeichnissen server und desktop gibt.

```
root@nemesis: pts/1: 21 files 1,8Mb -> diff /usr/portage/profiles/default-linux/x86/2006.1/make.defaults /usr/portage/profiles/default-linux/x86/2006.0/make.defaults

3c3

< # $Header: /var/cvsroot/gentoo-x86/profiles/default-linux/x86/2006.1/make.defaults,v 1.1 2006/07/26 20:30:23 wolf31o2 Exp $

---

> # $Header: /var/cvsroot/gentoo-x86/profiles/default-linux/x86/2006.0/make.defaults,v 1.12 2006/08/09 20:14:50 cardoe Exp $

5,7c5,7

< # This will be commented and replaced with just STAGE1_USE="unicode" if we do

< # not end up with a stable glibc 2.4 by 2006.1's release.

< STAGE1_USE="nptl nptlonly unicode"

---

> # This is currently commented so that the stage1 tarball can also be used to

> # build no-nptl systems.

> #STAGE1_USE="nptl"

9,10c9

< # These USE flags are what is common between the various sub-profiles.

< USE="cups gdbm gpm libg++ nptl nptlonly ppds udev unicode"

---

> USE="alsa apache2 apm arts avi cups eds emboss encode esd foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib jpeg kde libg++ libwww mad mikmod motif mp3 mpeg nptl ogg opengl oss pdflib png qt3 qt4 quicktime sdl spell truetype udev vorbis X xml xmms xv"
```

Beim nächsten Mal passe ich besser auf, es hätte aber schon irgendwo stehen können dass die make.profile nun viel weniger useflags enthält.

----------

## mv

 *Doe John wrote:*   

> Wenn ich also den Compiler komplett deinstallieren würde könnte ich nicht nur keine neuen Programme kompilieren,sondern auch die vorhandenen wären unbrauchbar da evtl. Bibliotheken fehlen würden?

 

Richtig.

 *Quote:*   

> Wie machen das dann Binär-Distris die ja in der Regel erstmal keinen Compiler mitinstallieren?

 

Sie werden zumindest dessen Bibliotheken installieren. (Ev. mit Ausnahme von ein paar Paranoia-Sicherheitsdistributionen, wo möglicherweise alles statisch gelinkt ist).Last edited by mv on Sun Sep 03, 2006 12:08 pm; edited 1 time in total

----------

## mv

 *tuxian wrote:*   

> Beim nächsten Mal passe ich besser auf, es hätte aber schon irgendwo stehen können dass die make.profile nun viel weniger useflags enthält.

 

Offizieller kann man es doch kaum dokumentieren:

http://www.gentoo.org/doc/en/gentoo-upgrading.xml

Dort ist so ziemlich die einzige spezielle Information zu 2006.1:

Please note that the alpha/2006.1, amd64/2006.1 and x86/2006.1 profiles are very minimal. They all have a desktop sub-profile that is likely what you want on a desktop machine.

----------

## tuxian

Danke das habe ich überlesen oder es war noch nicht zu sehen als ich auf 2006.1 umgestiegen bin.

Hoffentlich wird auch mal die dt. Seite upgedated.

----------

## Finswimmer

 *mv wrote:*   

>  *Doe John wrote:*   Wenn ich also den Compiler komplett deinstallieren würde könnte ich nicht nur keine neuen Programme kompilieren,sondern auch die vorhandenen wären unbrauchbar da evtl. Bibliotheken fehlen würden? 
> 
> Richtig.
> 
>  *Quote:*   Wie machen das dann Binär-Distris die ja in der Regel erstmal keinen Compiler mitinstallieren? 
> ...

 

Man lese gerne meinen Thread dazu.

Ich hatte nämlich glibc gekillt, und dann geht da auch nichts mehr...

----------

## franzf

 *achimh wrote:*   

> hallo
> 
> hab jetzt auch von gcc 3.3.4 auf 4.1.1 umgestellt und bei emerge -eav world hat er ma auch bei einem paket abgebrochen
> 
> hätt dann nur mehr 70 pakete oder so gehabt; hab jetzt den gcc 3.3.4 heruntergelöscht
> ...

 

Brauchste auch net, einfach

```
emerge --resume --skipfirst
```

Dann macht er das world-merge weiter. überspringt aber das fehlerhafte Paket (welches du dir nachher zur Ausbesserung notierst  :Wink: )

Grüße

Franz

----------

## tuxian

 *franzf wrote:*   

> 
> 
> Brauchste auch net, einfach
> 
> ```
> ...

 

Am besten mymerge verwenden, das macht das automatisch und gibt am Ende eine Liste mit den übersprungenen Paketen aus.

----------

## Finswimmer

 *tuxian wrote:*   

>  *franzf wrote:*    *achimh wrote:*   hallo
> 
> hab jetzt auch von gcc 3.3.4 auf 4.1.1 umgestellt und bei emerge -eav world hat er ma auch bei einem paket abgebrochen
> 
> hätt dann nur mehr 70 pakete oder so gehabt; hab jetzt den gcc 3.3.4 heruntergelöscht
> ...

 

Schade finde ich, dass nichts als Ausgabe zurück kommt, wenn alles gut durchläuft...War da am Anfang irritiert, nachdem ich aber im Code nachgeschaut hatte, dann doch beruhigt, dass alles gut lief...

Tobi

----------

## Storm.Xapek.de

Hab den gcc grad upgedatet und bin jetzt an emerge -e system,

da fällt mir gerade auf als cih diesen thread hier lese das meine

/etc/make.profile noch auf ../usr/portage/profiles/default-linux/x86/2005.1

steht. 

Sollte ich das noch umändern auf ../usr/portage/profiles/default-linux/x86/2006.1/desktop?

Und muss ich dann emerge -e system nochmal laufen lassen (die use-flags von system

hab ich geprüft die stimmen so)?

----------

## tuxian

Ja würde ich auf /usr/portage/profiles/default-linux/x86/2006.1/desktop setzen.

Danach genügt ein "emerge -uD --newuse world" da damit dann nur die Pakete bei denen sich die useflags geändert haben neu gebaut werden was vollkommen genügt.

----------

## TheSmallOne

Hm, interessant. Vor einer Weile habe ic mal angesprochen, dass diese Profile doch der ideale Ort wären, um Unterscheidungen zwischen Server- und Desktopsystemen zu machen und jeweils entsprechende Useflags zu setzen, aber die meisten waren irgendwie nicht meiner Meinung... und jetzt wurde es doch so umgesetzt.

 *tuxian wrote:*   

> Beim nächsten Mal passe ich besser auf, es hätte aber schon irgendwo stehen können dass die make.profile nun viel weniger useflags enthält.

 

Hm, sowas merkt man doch, oder nicht?

Davon abgesehen: Als ich mein System das erste Mal aufgesetzt habe, bin ich die komplette Liste der Useflags durchgegangen und habe sie entweder explizit gesetzt oder eben nicht. Ist das nicht das normale Vorgehen?

----------

## tuxian

Mein Fehler war dass ich ein "emerge -e world" gemacht habe ohne vorher die useflags zu kontrollieren.

Habe einfach nicht bedacht dass sie sich durch den profile-Wechsel ändern werden.

----------

## achimh

 *tuxian wrote:*   

>  *franzf wrote:*   
> 
> Brauchste auch net, einfach
> 
> ```
> ...

 

Hallo franzf und tuxia

Danke für die Hinweise!

Werde jetzt doch noch die fehlenden Pakete mit dem neuen Gcc-4.11 kompilieren.   :Smile: 

----------

## franzf

 *tuxian wrote:*   

>  *franzf wrote:*   
> 
> Brauchste auch net, einfach
> 
> ```
> ...

 

Schon klar, aber er hat ja schon ohne mymerge angefangen, und bis er das neue Tool hat isser auch ohne durch  :Wink: 

Außerdem wurde mymerge in letzter Zeit (auch in diesem Thread) so oft erwähnt, dass man nur so darüber stolpern muss ^^

Grüße

Franz

----------

## mv

 *TheSmallOne wrote:*   

> Davon abgesehen: Als ich mein System das erste Mal aufgesetzt habe, bin ich die komplette Liste der Useflags durchgegangen und habe sie entweder explizit gesetzt oder eben nicht. Ist das nicht das normale Vorgehen?

 

Das hatte ich früher auch gemacht, aber irgendwann wurde es mir zu dumm, die ganze Liste durchzugehen, wenn man doch nur sehen will, was sich geändert hat - zumal bei fast jedem emerge --sync das eine oder andere Flag hinzukommt/verschwindet/umbenannt wird oder gar seinen Default ändert. In Gentoo gibt es dazu m.W. kein Tool, aber hier gibt es eins (useflags.tar.gz): http://www.mathematik.uni-wuerzburg.de/~vaeth/gentoo/index.html

----------

## TheCurse

 *Doe John wrote:*   

>  *SinoTech wrote:*   
> 
> Viele der Bibliotheken, von denen das entstandene Programm abhängt, gehören zum Compiler. Updatest du den Compiler und möchtest den alten entfernen (Was ja meistens so ist), müssen die Programme gegen die Bibliotheken des neuen Compilers gelinkt werden.
> 
>  
> ...

 

Nein, aber wenn du bestimmte Bibliotheken deinstallierst funktioniert der Compiler nicht mehr  :Wink: 

----------

## mv

 *TheCurse wrote:*   

> Nein, aber wenn du bestimmte Bibliotheken deinstallierst funktioniert der Compiler nicht mehr 

 

Nein, auch die Programme selbst nicht. Du kannst es ja mal ausprobieren, wenn auf Deinem System gerade nichts Wichtiges läuft:

```

# mv -i /usr/lib/gcc/i686-pc-linux-gnu 1    

# eix # oder irgendein anderes C++-Programm

eix: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

# mv 1 /usr/lib/gcc/i686-pc-linux-gnu  

```

----------

## tuxian

Hab jetzt mal revdep-rebuild laufen lassen:

```
root@nemesis: pts/1: 21 files 1,9Mb -> revdep-rebuild

Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update

will be emerged.

Collecting system binaries and libraries... done.

  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...

  broken /usr/lib/avifile-0.7/ac3pass.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/ac3pass.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/audiodec.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/audiodec.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/avifile-0.7/divx4.la (requires /-lstdc++)

  broken /usr/lib/avifile-0.7/ffmpeg.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/ffmpeg.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/mad_audiodec.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/mad_audiodec.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/mp3lame_audioenc.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/mp3lame_audioenc.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/mp3lamebin_audioenc.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/mp3lamebin_audioenc.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/mpeg_audiodec.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/mpeg_audiodec.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/osmjpeg.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/osmjpeg.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/vorbis_audio.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/vorbis_audio.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/win32.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/win32.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/avifile-0.7/xvid4.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/avifile-0.7/xvid4.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/art.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/avi.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/avs.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/bmp.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/caption.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/cin.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/cip.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/clip.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/cmyk.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/cut.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/dcm.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/dib.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/dot.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/dps.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/dpx.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ept.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/fax.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/fits.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/gif.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/gradient.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/gray.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/histogram.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/html.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/icon.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/jpeg.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/label.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/magick.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/map.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mat.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/matte.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/meta.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/miff.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mono.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mpc.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mpeg.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mpr.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/msl.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mtv.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/mvg.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/null.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/otb.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/palm.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pattern.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pcd.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pcl.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pcx.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pdb.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pdf.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pict.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pix.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/plasma.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/png.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pnm.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/preview.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ps2.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ps3.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/psd.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ps.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/pwp.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/raw.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/rgb.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/rla.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/rle.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/scr.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/sct.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/sfw.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/sgi.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/stegano.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/sun.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/svg.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/tga.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/tiff.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/tile.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/tim.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ttf.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/txt.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/uil.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/url.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/uyvy.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/vicar.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/vid.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/viff.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/wbmp.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/wmf.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/wpg.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/xbm.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/xcf.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/xc.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/x.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/xpm.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/xwd.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/ycbcr.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/coders/yuv.la (requires /-lstdc++)

  broken /usr/lib/ImageMagick-6.2.0/modules-Q16/filters/analyze.la (requires /-lstdc++)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkio.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkdeui.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkdesu.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkwalletclient.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkdecore.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libDCOP.la)

  broken /usr/lib/kde3/mldonkeyapplet.la (requires /usr/kde/3.3/lib/libkdefx.la)

  broken /usr/lib/libaviplay.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/libaviplay.la (requires /usr/lib/libaviplayavcodec.la)

  broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavformat.la)

  broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavcodec.la)

 done.

  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.

  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.

  (/root/.revdep-rebuild.5_order)

Dynamic linking on your system is consistent... All done.
```

Anscheinend gehören diese Dateien / Bibliotheken zu keinen ebuilds (mehr).

Ich habe sie jetzt einfach gelöscht!

Macht das etwas?

----------

## mv

 *tuxian wrote:*   

> 
> 
> ```
> 
>   ...
> ...

 

Also mal der Reihe nach: avifile gibt es nicht mehr. Also ist vermutlich das gesamte /usr/lib/avifile-0.7 löschbar;

vermutlich evenfalls die Dateien am Schluss, die auf /usr/lib/libavi* zugreifen.

Die anderen gehören wohl zu imagemagick oder kmldonkey oder alten Versionen davon. Sicherheitshalber würde ich nach dem Löschen der Files diese beiden Pakete nochmals emergen. Ist vermutlich nicht notwendig, da es vermutlich nur Überreste von älteren Installationen sind, aber sicher ist sicher (zumindest theoretisch könnten sie auch zur Laufzeit von neueren Versionen geschrieben worden sein, so dass Portage deswegen nichts davon weiß - ist bei .la-Files aber sehr unwahrscheinlich).

----------

## tuxian

Okay danke, ich tu sicherheitshalber ImageMagick neu emergen.

----------

## Klaus Meier

Hatte ja weiter vorne über meine Probleme mit -O3 geschrieben. Es ist gerade der gcc-4.1.1-r1 rausgekommen. Die Pakete, die sich beim 4.1.1 nicht übersetzen ließen, gehen jetzt durch.

----------

## tuxian

Ist aber noch unstable.

----------

## Klaus Meier

 *tuxian wrote:*   

> Ist aber noch unstable.

 

Das ist jetzt ein Schwachsinn mit stable und testing, den ich nicht verstehe. Der Compiler aus stable macht bei mir Probleme, der aus testing erst mal weniger. Ok, ist noch zu neu um schlußendlich was zu sagen, aber es sieht schon mal besser aus, als der alte.

Warum ist alte Software per definitionen immer stable und neue unstable? Es sind doch gerade beim r1 Fehler gefixt worden und keine neuen Funktionen dazugekommen. Fehler in der Software verschwinden doch nicht, wenn man etwas drei Monate im testing hat und es dann ins stable tut, sondern in dem man gefundene Fehler beseitigt.

Für mich ist eher der 4.1.1-r1 stable als der 4.1.1.

----------

## nikaya

Habe gerade emerge -e world laufen und er brach bei emerge -e system bei 2 Paketen ab:sys-libs/db und sys-libs/pam.

Die Fehlermeldung war (sinngemäß):

```
c-compiler cannot create executables
```

Muß dazu sagen dass ich 2 Gentoo-Systeme am laufen habe:testing und stable.Der Fehler taucht nur bei testing auf.

Ich werde,wenn "world" durch ist,nochmal schauen ob's mit gcc-4.1.1-r1 klappt.

----------

## sidious

muss ich wenn ich auf 4.1.1-r1 wechseln will auch nochmal emerge -e system und emerge -e world machen?

oder reicht es 4.1.1-r1 ~x86 in package.keywords einzutragen und dann emerge -avu gcc ?

----------

## tuxian

Nein "emerge -e world" ist nicht notwendig wenn du auf gcc-4.1.1-r1 wechselst.

Ist ja immer noch eine gcc-Version.

----------

## nikaya

 *sidious wrote:*   

> muss ich wenn ich auf 4.1.1-r1 wechseln will auch nochmal emerge -e system und emerge -e world machen?
> 
> oder reicht es 4.1.1-r1 ~x86 in package.keywords einzutragen und dann emerge -avu gcc ?

 

"emerge -uav gcc" reicht völlig."r1" ist ja nur eine Revision.Komplett neu bauen ist nur bei größeren Versionssprüngen nötig wenn die ABI sich geändert hat.Dann wird auch oft in den Dokus darauf hingewiesen.

----------

## Klaus Meier

Ich mache gerade ein emerge -e world. Einfach deshalb, weil KDE bei mir immer einige Macken hatte, wo einfach was nicht funktioniert hat. Also bei einigen Dateien auf dem Desktop bekomme ich eine Vorschau, bei anderen nicht. Hab da immer auf KDE geschimpft und gesagt, Gnome ist viel stabiler. Vielleicht lag es ja am gcc.

----------

## TheSmallOne

Ich hab' hier ein Problem mit dem Update auf den GCC 4.1.1.

Auf meinem ersten Rechner ist es ohne Probleme durchgelaufen, aber auf einem anderen Rechner bleibt es an folgender Stelle hängen:

```

Automaton `k6_store_unit'

       68 NDFA states,            233 NDFA arcs

       68 DFA states,             233 DFA arcs

       37 minimal DFA states,     126 minimal DFA arcs

      273 all insns          6 insn equivalence classes

  140 transition comb vector els,   222 trans table els: use simple vect

  140 state alts comb vector els,   222 state alts table els: use simple vect

  222 min delay table els, compression factor 1

Automaton `k6_integer_units'

      114 NDFA states,            396 NDFA arcs

      114 DFA states,             396 DFA arcs

      114 minimal DFA states,     396 minimal DFA arcs

      273 all insns         11 insn equivalence classes

  471 transition comb vector els,  1254 trans table els: use comb vect

  471 state alts comb vector els,  1254 state alts table els: use comb vect

 1254 min delay table els, compression factor 1

Automaton `k6_fpu_unit'

       58 NDFA states,            120 NDFA arcs

       58 DFA states,             120 DFA arcs

       57 minimal DFA states,     118 minimal DFA arcs

      273 all insns          5 insn equivalence classes

  120 transition comb vector els,   285 trans table els: use simple vect

  120 state alts comb vector els,   285 state alts table els: use simple vect

  285 min delay table els, compression factor 1

Automaton `k6_branch_unit'

        2 NDFA states,              5 NDFA arcs

        2 DFA states,               5 DFA arcs

    15522 DFA states,           99908 DFA arcs

      463 minimal DFA states,    3038 minimal DFA arcs

      273 all insns         21 insn equivalence classes

 3057 transition comb vector els,  9723 trans table els: use comb vect

 3057 state alts comb vector els,  9723 state alts table els: use comb vect

 9723 min delay table els, compression factor 1

17533 all allocated states,     102661 all allocated arcs

32710 all allocated alternative states

 6256 all transition comb vector els, 16780 all trans table els

 6256 all state alts comb vector els, 16780 all state alts table els

16780 all min delay table els

    0 locked states num

  transformation: 0.080005, building DFA: 76.624790

  DFA minimization: 2.580160, making insn equivalence: 0.008001

 all automaton generation: 81.429090, output: 0.756048

/bin/sh /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c

insn-attrtab.c is unchanged

echo timestamp > s-attrtab

stage1/xgcc -Bstage1/ -B/usr/i586-pc-linux-gnu/bin/   -O2 -march=k6 -pipe -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/. -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/../include -I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/gcc/../libcpp/include     -c insn-attrtab.c \

  -o insn-attrtab.o
```

Von da an reagiert der Rechner fast gar nicht mehr und die Festplatte läuft wie wild. So wie es aussieht ist der Speicher nahezu voll und es wird kräftig geswappt. Aber trotzdem tut sich irgendwie nichts...

Achja: Hab' etwa 64MiB Speicher und eine Swap-Partition von 500MiB.

Irgendeine Idee, wie ich das ganze kompiliert bekomme?

----------

## Klaus Meier

Schraub mal die Optimierungen runter. Also -O oder -Os. Als nächstes -pipe raus. Dann hilft eventuell noch eine reine Textkonsole, also nix X.

Bei 64MB solltest du sowieso alles mit -Os machen.

----------

## TheSmallOne

 *Klaus Meier wrote:*   

> Schraub mal die Optimierungen runter. Also -O oder -Os. Als nächstes -pipe raus. Dann hilft eventuell noch eine reine Textkonsole, also nix X.

 

Nach einer weiteren Nacht, in der außer der Festplatte nichts gelaufen ist muß ich leider feststellen, dass es nichts gebracht hat.

X habe ich sowieso nicht, das ist nämlich Hauptsächlich Router und Fileserver.

 *Quote:*   

> Bei 64MB solltest du sowieso alles mit -Os machen.

 

Wieso?

BTW, wie kommt das eigentlich, dass der da nur noch rumswappt? Es scheint ja nicht so viel Speicher benötigt zu werden, dass er komplett volllaufen würde, dann gäbe es ja sicher sowas wie einen Out-of-Memory Fehler. Aber dass da gar nichts mehr passiert außer rumgeswappe scheint mir doch igendwie fehlerhaft zu sein.

----------

## SinoTech

 *TheSmallOne wrote:*   

> 
> 
> [...]
> 
>  *Quote:*   Bei 64MB solltest du sowieso alles mit -Os machen. 
> ...

 

 *man gcc wrote:*   

> 
> 
> [...]
> 
>  -Os Optimize for size.  -Os enables all -O2 optimizations that do not typically increase code size.  It also performs fur-
> ...

 

 *TheSmallOne wrote:*   

> 
> 
> [...]
> 
> BTW, wie kommt das eigentlich, dass der da nur noch rumswappt? Es scheint ja nicht so viel Speicher benötigt zu werden, dass er komplett volllaufen würde, dann gäbe es ja sicher sowas wie einen Out-of-Memory Fehler. [...]
> ...

 

Swap ist da um den physikalischen Speicher zu vergrößern, d.h. ist nicht genug physik. Speicher vorhanden, werden zur Zeit nicht benötigte Teile vom physik. Speicher in den Swap ausgelagert. Ein "Out-Of-Memory" Fehler würde kommen wenn zusätzlich auch noch der Swap voll ist.

Mfg

Sino

----------

## Klaus Meier

Und Festplattenspeicher ist halt um den Faktor 1000 (einfach mal so geraten) langsamer als Hauptspeicher. Und dann dauert es auch um diesen Faktor länger.

-Os benutzt nur Optimierungen, die den Code nicht vergrößern. Und mit 64 MB Speicher bist du nicht so gut dabei.

----------

## schachti

Da kommt man aus dem Urlaub zurück, und schon muß man das komplette System neu kompilieren.   :Laughing: 

In irgend einem Thread gab's vor einiger Zeit mal ein kurzes Skript, das es einem erspart, beim emerge -e world diejenigen Pakete nochmal zu kompilieren, die beim vorigen emerge -e system bereits mit dem neuen gcc kompiliert worden sind. Hat da jemand einen Link zur Hand bzw. kann sagen, ob das in diesem Fall sinnvoll ist?

----------

## jonny_mc_conny

ich habe vorher gcc-4.1.1 benutzt und update gerade auf 4.1.1-r1.

nun weiß ich nicht genau, ob die frage schon gestellt wurde, da ich ein wenig unter zeitdruck bin, aber eigentlich ist sie auch viel zu banal:

muss ich auch ein

```
# gcc-config i686-pc-linux-gnu-4.1.1-r1
```

ausführen oder reicht meine aktuelle einstellung auf 4.1.1

ich bin mir nicht ganz sicher, ob diese revisionen (ich hoffe das is das richtige wort) noch der gcc-config mitgeteilt werden müssen.

----------

## schachti

Ich vermute, das ist nicht nötig - laß Dir doch einfach mal mit gcc-config -l anzeigen, welche gcc-Versionen installiert und welche Version als default-Compiler ausgewählt ist.

----------

## TheSmallOne

 *SinoTech wrote:*   

> Swap ist da um den physikalischen Speicher zu vergrößern, d.h. ist nicht genug physik. Speicher vorhanden, werden zur Zeit nicht benötigte Teile vom physik. Speicher in den Swap ausgelagert. Ein "Out-Of-Memory" Fehler würde kommen wenn zusätzlich auch noch der Swap voll ist.

 

Mir ist schon klar, was Swap ist.

Aber hier liegt ja offenbar ein Fall vor, in dem der Speicher (+Swap) nicht voll wird, aber trotzdem kein Fortschritt erreicht wird, da der Rechner ja praktisch "stehenbleibt". Also im Prinzip irgendeine Art von Endlosschleife, und sowas sollte ja besser nicht vorkommen.

 *Klaus Meier wrote:*   

> Und Festplattenspeicher ist halt um den Faktor 1000 (einfach mal so geraten) langsamer als Hauptspeicher. Und dann dauert es auch um diesen Faktor länger.

 

Wie lange kann es denn dauern? Ich habe etwa 12 Stunden gewartet. Und das ist ja bloß ein Befehl... sicherlich nicht der Letzte in dieser Kompilation. Alle vorherigen Schritte liefen jedenfalls recht zügig.

 *Quote:*   

> -Os benutzt nur Optimierungen, die den Code nicht vergrößern. Und mit 64 MB Speicher bist du nicht so gut dabei.

 

Also es war die letzten 6-8 Jahre ausreichend, warum sollte es denn jetzt plötzlich zu wenig sein? Soo viel größer kann der GCC doch auch nicht geworden sei.

----------

## think4urs11

 *schachti wrote:*   

> In irgend einem Thread gab's vor einiger Zeit mal ein kurzes Skript, das es einem erspart, beim emerge -e world diejenigen Pakete nochmal zu kompilieren, die beim vorigen emerge -e system bereits mit dem neuen gcc kompiliert worden sind. Hat da jemand einen Link zur Hand bzw. kann sagen, ob das in diesem Fall sinnvoll ist?

 

'state of the art' ist momentan das da: https://forums.gentoo.org/viewtopic-t-494331.html

die Variante die du wahrscheinlich meinst müßte diese sein: https://forums.gentoo.org/viewtopic-t-282474.html

ausprobiert habe ich persönlich beide noch nicht.

 *TheSmallOne wrote:*   

>  *Quote:*   -Os benutzt nur Optimierungen, die den Code nicht vergrößern. Und mit 64 MB Speicher bist du nicht so gut dabei. Also es war die letzten 6-8 Jahre ausreichend, warum sollte es denn jetzt plötzlich zu wenig sein? Soo viel größer kann der GCC doch auch nicht geworden sei.

 

Hmm, Guenther scheint jemand zu sein der weiß wovon er redet (macht jedenfalls sehr den Eindruck) ... lies mal https://forums.gentoo.org/viewtopic-t-495539.html

----------

## mv

 *TheSmallOne wrote:*   

>  *Quote:*   -Os benutzt nur Optimierungen, die den Code nicht vergrößern. Und mit 64 MB Speicher bist du nicht so gut dabei. 
> 
> Also es war die letzten 6-8 Jahre ausreichend, warum sollte es denn jetzt plötzlich zu wenig sein? Soo viel größer kann der GCC doch auch nicht geworden sei.

 

Der gcc nicht, aber sein Speicherbedarf schon. Bei kmail beispielsweise braucht er bei mir (immerhin 500MB RAM) glatte 2.5 Stunden zum Compilieren von einer einzigen Datei - mit make-option -j1, ohne -pipe, ohne Optimierungen - weil er einfach nur am swappen ist. Der gcc-3.x hatte mit -O3 für diese Datei auch lange gebraucht, aber mit -O2 und erst recht mit -O0 war das noch kein Thema gewesen, nicht einmal mit der Hälfte des RAM. Glücklicherweise ist kmail das negativste Beispiel. Wenn man aber natürlich sogar nur 1/8 des RAMs hat...

----------

## TheSmallOne

Okay, dann sieht es wohl so aus, als müsste ich auf den GCC 4.1.1 verzichten.

Wie lange wird es wohl dauern, bis ich da Probleme bekomme, weil irgendwelche andere Software unbedingt diese Version vorraussetzt?

----------

## Klaus Meier

Ich hatte mit dem gcc 4.1.1 immer einige Probleme. Gewissen Pakete gingen mit -O3 nicht durch oder funktionierten damit nicht. Gut, das darf sein. Aber auch mit -O2 funktionierte einiges nicht richtig sondern verhielt sich komisch, besonders unter KDE. Habe da immer auf das instabile KDE geschimpft und Gnome benutzt, weil es da weniger Probleme gab.

Und nun der 4.1.1-r1. Die Probleme unter KDE sind bei -O2 weg. Die Pakete, die vorher mit -O3 nicht wollten, gehen jetzt durch. Ob es bei -O3 auch zuverlässig läuft, weiß ich noch nicht. Gut, es können beim r1 auch noch Probleme auftreten.

Aber nach dem, was ich erlebt habe: Benutzt den 4.1.1-r1 und macht ein emerge -e world. Euer Gentoo wird es euch danken.

----------

## amne

Habe Klaus Meiers post einmal hier angehangen.

 *Klaus Meier wrote:*   

> Ich hatte mit dem gcc 4.1.1 immer einige Probleme. Gewissen Pakete gingen mit -O3 nicht durch oder funktionierten damit nicht. Gut, das darf sein. Aber auch mit -O2 funktionierte einiges nicht richtig sondern verhielt sich komisch, besonders unter KDE. Habe da immer auf das instabile KDE geschimpft und Gnome benutzt, weil es da weniger Probleme gab.

 

Da gcc 4.1 jetzt ja stable ist sollte er auch in der Lage sein, das gesamte stable zu kompilieren. Ich hab zwar kein kde, aber ein paar kde-Programme (kpdf, korganizer und ein paar andere Kleinigkeiten), da gab es auch mit -O3 bei emerge -e keine Probleme mehr.

----------

## Storm.Xapek.de

Wo liegt den eigentlich der Unterschied zwischen gcc-4.1.1

und gcc-4.1.1-r1?

Ist da nur ein harmloser Bug gefixt worden oder ist da

ein grundlegender Fehler im 4.1.1 behoben worden

Ich habe nämlich in diesem Augenblick nach ziemlich genau 24h

dauerkompilieren mein emerge -e world fertig, mit 4.1.1.

Sollte man jetzt nochmal alles neukompilieren?   :Shocked: 

----------

## Klaus Meier

 *Storm.Xapek.de wrote:*   

> Wo liegt den eigentlich der Unterschied zwischen gcc-4.1.1
> 
> und gcc-4.1.1-r1?
> 
> Ist da nur ein harmloser Bug gefixt worden oder ist da
> ...

 

Was da geändert wurde hab ich auch noch nicht gefunden. Nur, wenn es irgendwelche Probleme gibt, dann weißt du, woran es liegen könnte. Einen zwingen Grund, damit alles noch mal zu übersetzen gibt es nicht, solange alles läuft.

----------

## b3cks

Das ist auch nicht gerade super aussagekräftig, aber es scheint ja nicht allzu wild zu sein.

http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/sys-devel/gcc/ChangeLog

 *Quote:*   

> *gcc-4.1.1-r1 (03 Sep 2006)
> 
>   03 Sep 2006; Mike Frysinger <vapier@gentoo.org> gcc-4.1.1.ebuild,
> 
>   +gcc-4.1.1-r1.ebuild:
> ...

 

----------

## franzf

```
# diff gcc-4.1.1.ebuild gcc-4.1.1-r1.ebuild

3c3

< # $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.1.1.ebuild,v 1.20 2006/09/05 16:56:06 kumba Exp $

---

> # $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.1.1-r1.ebuild,v 1.1 2006/09/03 22:53:47 vapier Exp $

5c5

< PATCH_VER="1.6"

---

> PATCH_VER="1.7"

19c19

< KEYWORDS="-* amd64 hppa mips ppc ~ppc64 ~s390 x86 ~x86-fbsd"

---

> KEYWORDS="-* ~amd64 ~hppa ~mips ~ppc ~ppc64 ~s390 ~x86 ~x86-fbsd"

```

Änderungen im CVS-Header, Patch_Ver und Keywords. Da für das Bauen 1 und 3 wurscht sind muss die PATCH_VER für die Änderungen verantwortlich sein.

Kann mir jemand sagen was es hiermit auf sich hat? Google spuckt seitenweise Ebuilds aus, aber keine Erleuterung...

Thx

Franz

----------

## Finswimmer

-rw-rw-r--   1 root     46341 2006-09-04 03:07 gcc-4.1.1-patches-1.7.tar.bz2

-rw-rw-r--   1 root     20981 2006-09-04 03:07 gcc-4.1.1-uclibc-patches-1.1.tar.bz2

Die sind neu dazu gekommen, bzw haben weitere Patches bekommen.

Tobi

----------

## Erdie

BTW:

GCC4.1.1 macht immer noch Schwierigkeiten bei verschiedenen Paketen. Qemu läßt sich nicht bauen, Hydrogen schmeißt einen Fehler und Ardour enthält GUI Fehler, wenn es mit GCC4.1.1 übersetzt ist. Ehrlich gesagt habe ich ein schlechtes Gefühl jetzt mit einem Mischsystem rumhantieren zu müssen wo ich doch in diesem Monat eine wichtige Recordingsession mit Ardour mache und ich Ardour mit gcc3.4.6 recompilieren mußte. Instabilitäten kann man sich beim Recorden wahlich nicht leisten und die Musiker werden mich kreuzigen wenn ich sage, wir müssens nochmal einspielen weil die Software abgeschmiert ist.

Diese ist der Bug in Ardour, das mit gcc4.1.1 gebaut wurde:

http://www.erdie.de/ardour-error.png

--> die location marker Leiste ist nach rechts verschoben, was sich auch nicht durch ein Reset der Konfiguration beheben läßt.

Wenn ich von solchen Problemen gewußt hätte, wäre ich nicht auf die Idee gekommen auf 4.1.1 zu wechseln.

-Erdie

----------

## ConiKost

 *Doe John wrote:*   

> Habe gerade emerge -e world laufen und er brach bei emerge -e system bei 2 Paketen ab:sys-libs/db und sys-libs/pam.
> 
> Die Fehlermeldung war (sinngemäß):
> 
> ```
> ...

 

Komisch, ich fahre testing seit ca. 3 Jahren und keine Probleme bisher.

----------

## lutzlustig

Hallo,

 *flammenflitzer wrote:*   

> 
> 
> Die von AMD empohlenen Compileroptionen (generic Performance Switches)  (-O3 -ffast-math -funroll-all-loops -ftracer -funswitch-loops -ftree-vectorize) bei Version 3.... (-O3 -ffast-math -funroll-all-loops -fpeel-loops -ftracer -funswitch-loops -funit-at-a-time)
> 
> Die entscheidende Frage ist: Was bringt es? Bin ich nur up-to-date, oder bekomme ich einen Performance-Schub.

 

Welches ist für welchen GCC? das erste für den 4er und das zweite für den 3er? Oder Umgekehrt?

Ciao

----------

## Klaus Meier

Habe jetzt mal etwas rumprobiert und auch Compileroptionen ausprobiert. Dabei ergab sich für einen Athlon64/32-bit System folgendes.

CFLAGS=-O2 -fomit-frame-pointer und sonst nichts.

-O3 und einiges von dem, was AMD da sonst noch so empfiehlt, Finger weg. Schrottet dir die Kiste. Ist echt egal, ob man da den gcc-4.1.1 oder den gcc-4.1.1-r1 verwendet. Geht mit beiden nicht.

----------

