[gentoo] GCC update troubles

[deepbass909]

Ik ben bezig met een totale system rebuild om over te stappen op gcc 3.4.5.
Ik volg daarvoor de guide die op www.gentoo.org te vinden is.
GCC installeren gaat goed en ik heb met succes de nieuwe compiler kunnen selecteren.

De volgende stap is om GCC opnieuw te compileren met de 3.4.5 compiler, zodat hij zichzelf optimaliseerd. Dat gaat ook nog goed.

Dan komt de volgende stap van een system rebuild zodat ik ook echt kan profiteren van de nieuwe functies. Ik hou daarvoor netjes de guide aan, maar heb ineens met een redelijk aantal pakketten problemen om te ze kunnen compileren. Zo gaat op het moment nas fout (veel dependencies ontbreken met betrekking tot installatie gerelateerde software zoals rman). En nu krijg ik met geen mogelijkheid MC gecompileerd.

code:

../vfs/libvfs-mc.a(smbfs.o): In function `loaddir_helper':
smbfs.c:(.text+0xa00): undefined reference to `LocalTime'
../vfs/libvfs-mc.a(smbfs.o): In function `smbfs_get_path':
smbfs.c:(.text+0x19f5): undefined reference to `write_socket'
collect2: ld gaf exit-status 1 terug
make[2]: *** [mc] Fout 1
make[2]: *** Wachten op onafgeronde taken...
make[2]: Leaving directory `/var/tmp/portage/mc-4.6.0-r13/work/mc-4.6.0/src'
make[1]: *** [all-recursive] Fout 1
make[1]: Leaving directory `/var/tmp/portage/mc-4.6.0-r13/work/mc-4.6.0'
make: *** [all] Fout 2

!!! ERROR: app-misc/mc-4.6.0-r13 failed.
Call stack:
  ebuild.sh, line 1573:   Called dyn_compile
  ebuild.sh, line 982:   Called src_compile

!!! (no error message)
!!! If you need support, post the topmost build error, and the call stack if relevant.

Helaas kan ik met deze fout maar heel weinig. Het is een mc versie die ik al eerder had gecompileerd en toen wel goed. Het enige dat veranderd is, is dus de gcc versie.

Mijn gcc optimalisaties zijn niet spectaculair ofzo, dus ik zit dus behoorlijk vast (vooral omdat bepaalde dingen niet echt meer werken...)

code:

CFLAGS="-Os -march=athlon-xp -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

Wie o wie kan mij helpen (terug naar gcc-3.3.6 lijkt niks uit te halen...)

[Verwijderd]

Ten eerste:

code:

Important: If you're looking for instructions specific to upgrades from GCC-3.3 to GCC-3.4 or greater, please consult the dedicated section.

Dat had je sowieso als eerste moeten zien, en daar moet je ook heen.
In jouw geval zijn er nu flink wat packages kapot doordat ze met een oudere GCC gecompiled zijn, in je voorbeeld dus bijvoorbeeld samba.
Een recompile van samba zou de errors die je met MC krijgt verhelpen.

Ik weet niet in hoeverre je die tutorial gevolgd hebt, en wat je allemaal uitgespookt hebt, maar:

code:

emerge sys-libs/libstdc++-v3  && revdep-rebuild --library libstdc++.so.5

zou al een mooi begin zijn en de meeste broken packages fixen en er voor zorgen dat v3 packages gewoon nog werken.

En DAN kan je je hele system rebuilden als je daar zin in hebt, persoonlijk zie ik daar nooit zo het nut van in, nutteloos stroomverbruik voor 0.1 seconde snelheidswinst, bovendien compileer je in de loop der tijd toch alles wel met de nieuwe GCC bij updates.
Maargoed:

code:

emerge -eav system && emerge -eav world && emerge -aC =sys-devel/gcc-3.3*

Je compiler flags zijn inderdaad niet de oorzaak, die zijn doodnormaal.
Alhoewel je hopelijk weet dat -0s vooral optimized voor size en niet voor snelheid he?

[ Voor 35% gewijzigd door Verwijderd op 26-03-2006 13:29 ]

[deepbass909]

Misschien had ik iets duidelijker aan moeten geven dat ik de guide op de letter aan het volgen ben. Ik weet dat er een risico in zit.

Ik heb libstdc++-v3 opnieuw gecompileerd. Vervolgens emerge -e system om alle systeem pakketten opnieuw te compileren. Ook dat ging zonder problemen. Het gaat pas fout bij de user pakketten en ook nog geeneens alle.

Daarnaast staat mijn pc op het moment toch bijna 24/7 aan (het is m'n wekker en m'n laptop ondersteunt geen getimede boots). Dus echt extra stroom verbruik ik niet.

Ik wil m'n pc zoveel mogelijk up-to-date houden ivm xgl waarmee ik aan het testen ben.

[Verwijderd]

deepbass909 schreef op zondag 26 maart 2006 @ 13:39:
Misschien had ik iets duidelijker aan moeten geven dat ik de guide op de letter aan het volgen ben. Ik weet dat er een risico in zit.

Ik heb libstdc++-v3 opnieuw gecompileerd. Vervolgens emerge -e system om alle systeem pakketten opnieuw te compileren. Ook dat ging zonder problemen. Het gaat pas fout bij de user pakketten en ook nog geeneens alle.

Daarnaast staat mijn pc op het moment toch bijna 24/7 aan (het is m'n wekker en m'n laptop ondersteunt geen getimede boots). Dus echt extra stroom verbruik ik niet.

Ik wil m'n pc zoveel mogelijk up-to-date houden ivm xgl waarmee ik aan het testen ben.

Kijk eens goed naar de commando's die ik je geef.
En voer ze gewoon uit, ook al heb je libstdcc++-v3 al gecompiled.
Of voer iig de revdep-rebuild uit. Die zal alle broken packages fixen.
Een machine die compiled gebruikt trouwens meer stroom dan een machine die idled.

[irondog]

deepbass909 schreef op zondag 26 maart 2006 @ 13:00:
De volgende stap is om GCC opnieuw te compileren met de 3.4.5 compiler, zodat hij zichzelf optimaliseerd. Dat gaat ook nog goed.

Wtf? Een native compiler is altijd gecompileerd met zichzelf: alleen de eerste stage compiler is gecompileerd met de oude. Waar komt deze mythe nou weer vandaan?

En nu krijg ik met geen mogelijkheid MC gecompileerd.

Misschien moet je de volgorde van je rebuild aanpassen. Ik zou beginnen met Glibc en daarna samba. Je MC probs lijken te maken te hebben met samba. Eventueel kun je samba uit je USE flags halen.

Haal ook maar -Os uit je c-flags (niet dat ik zeg dat dat de veroorzaker is), maar alle flags anders dan -march=bla -O2 -fomit-frame-pointer vragen om gezeik.

Verwijderd schreef op zondag 26 maart 2006 @ 13:17:
Een recompile van samba zou de errors die je met MC krijgt verhelpen.

Ik heb ff niet gelezen dat jij al hetzelfde vermoeden als ik had.

En DAN kan je je hele system rebuilden als je daar zin in hebt, persoonlijk zie ik daar nooit zo het nut van in, nutteloos stroomverbruik voor 0.1 seconde snelheidswinst, bovendien compileer je in de loop der tijd toch alles wel met de nieuwe GCC bij updates.

Snelheid winnen? No way man! Dikke vette fragmentatie krijg je van dat gerebuild. Verder is dat rebuilden wel zo netjes voor je systeem consistentie, maar ik ben het helemaal met je eens: dat rebuilden gebeurt vroeg of laat vanzelf wel bij een update.

Alhoewel je hopelijk weet dat -0s vooral optimized voor size en niet voor snelheid he?

De hd is meestal de bottleneck in het gevoel voor snelheid van een systeem. Als Os echt zijn werk goed doet, win je vette snelheid bij in opstarttijden van applicaties.

Maar goed. CFLAGS tunen is voor mensen met teveel tijd of met een grote behoefte aan breakage van het systeem. -Os is niet veilig. Als je niet eens snapt wat een "undefined reference" betekent en dus nog nooit zelf met C gewerkt hebt, hoor je ook niet te experimenteren met compilers/linkers (laat staan leipe CFLAGS).

[ Voor 49% gewijzigd door irondog op 26-03-2006 18:19 ]

[deepbass909]

@Irondog
Als je een compiler compileerd, pakt hij altijd de actieve compiler om dat te kunnen doen. De eerste keer zal hij dus de oude compiler gebruiken. Vervolgens activeer je de nieuwe compiler en compileer je hem nog een keer. Deze keer met de laatste versie. Deze wijsheid komt van de gentoo.org pagina uit de link in mijn startpost.

Ik zal eens de volgorde met de hand uitvoeren, echter worden er 1000+ pakketten opnieuw gecompileerd, het is dus niet iets dat ik graag wil doen...

[irondog]

deepbass909 schreef op zondag 26 maart 2006 @ 18:25:
@Irondog
Als je een compiler compileerd, pakt hij altijd de actieve compiler om dat te kunnen doen. De eerste keer zal hij dus de oude compiler gebruiken. Vervolgens activeer je de nieuwe compiler en compileer je hem nog een keer. Deze keer met de laatste versie. Deze wijsheid komt van de gentoo.org pagina uit de link in mijn startpost.

Bullshit, onzin, mythe! Okee, misschien wist je het niet: dr wordt heel wat afgezwetst online. De betrouwbaarheid van een bron zou je toch in moeten kunnen schatten

http://gcc.gnu.org/onlinedocs/gccint/Makefile.html

When GCC is configured for a native configuration, the default action for make is to do a full three-stage bootstrap. This means that GCC is built three times—once with the native compiler, once with the native-built compiler it just built, and once with the compiler it built the second time. In theory, the last two should produce the same results, which `make compare' can check. Each stage is configured separately and compiled into a separate directory, to minimize problems due to ABI incompatibilities between the native compiler and GCC.

Koop dat je me deze keer gelooft als ik zeg dat gentoo daar niet vanaf wijkt.

[Verwijderd]

deepbass909 schreef op zondag 26 maart 2006 @ 18:25:
@Irondog
Als je een compiler compileerd, pakt hij altijd de actieve compiler om dat te kunnen doen. De eerste keer zal hij dus de oude compiler gebruiken. Vervolgens activeer je de nieuwe compiler en compileer je hem nog een keer. Deze keer met de laatste versie. Deze wijsheid komt van de gentoo.org pagina uit de link in mijn startpost.

Ik zal eens de volgorde met de hand uitvoeren, echter worden er 1000+ pakketten opnieuw gecompileerd, het is dus niet iets dat ik graag wil doen...

Het is ook je eigen schuld als je dat met de hand gaat doen.
Ik heb nu 2x tegen je gezegd dat je eerst revdep-rebuild moet draaien.
Dat is ervoor gemaakt om dit soort problemen op te lossen.

Lees man revdep-rebuild maar.

[deepbass909]

@fabio-C
Ja, ik ben in de goede sectie begonnen (3. Upgrading from GCC-3.3 to 3.4 or greater), ik ben geen complete linux noob inmiddels meer. Ik loop alleen nu even tegen iets aan wat me boven de pet gaat.

En als je de manual eens opent dan zie je dat er 2 methoden zijn om je systeem om te bouwen, 1 is met revdep-rebuild, de 2de met emerge -e system en emerge -e world.

@irondog
Ik geef je volledig gelijk dat er heel wat gelul op internet staat en dat je altijd kritisch moet zijn. Echter als ik sites als gentoo-wiki of gentoo.org niet meer mag geloven, welke dan wel??? Ik beschouw met name de 2de als zeer betrouwbaar.

Maar goed, dat neemt nog steeds niet weg dat ik op het moment een matig werkend systeem heb.

Of eigenlijk alles werkt, op m'n audio na.

Ik moet toegeven dat ik de stap met revdep-rebuild niet uitvoerde, omdat ik de methode met emerge -e system doe. Daarin is (blijkbaar) rebdep-rebuild niet nodig.

Wat betreft de optimalisatie vlaggen. Ik ben me er wel degelijk van bewust dat -Os wellicht een extreme vlag kan zijn. Ik moet echter uitgaan van de info die ik vind in guides van Gentoo en Gentoo-wiki. En daaruit maakte ik op dat -Os goed te gebruiken is als je zelf geen software schrijft en geen debug info nodig hebt. Ik heb hem niet zomaar gekozen (hij stond eerst op -O2).
Wat betreft de snelheidswinst, die kan op mijn laptop toch wel merkbaar zijn, aangezien hij maar een 4200rpm schijfje heeft en ik al meerdere keren heb ondervonden dat de harddisk z'n prestaties drukte. En size optimized compilatie heeft voor mij dus wel degelijk nut.

[ Voor 7% gewijzigd door deepbass909 op 26-03-2006 18:58 ]

[deepbass909]

ARGH!!!
Ik word lichtelijk gestoord van portage en revdep-rebuild. Veel van de nieuwe pakketten hebben als use-flag een gele flag met een % erachter (bijvoorbeeld bij compiz paint-patch%). Dit schijnt aan te geven dat het gewoon een nieuwe use-flag is ten opzichte van de geïnstalleerde versie.
Ok, niks mis mee zou je zeggen.

Echter klaagt revdep-rebuild bij elk pakket met zo'n vlag dat hij een onbekende use-flag tegenkomt en kapt dan... De use-flag instellen en re-emerge doen werkt...

ps. voor dat jullie gaan zeggen dat ik mijn portage moet update, dat is al de laatste versie.

[irondog]

deepbass909 schreef op zondag 26 maart 2006 @ 18:56:
@irondog
Ik geef je volledig gelijk dat er heel wat gelul op internet staat en dat je altijd kritisch moet zijn. Echter als ik sites als gentoo-wiki of gentoo.org niet meer mag geloven, welke dan wel??? Ik beschouw met name de 2de als zeer betrouwbaar.

Maar waar staat dat dan precies? Tis namelijk echte, echte onzin. Net ff gcc-4.0.3 ge-emerged met gcc-4.1 als systeem compiler. GCC4.1 is alleen gebruikt voor de eerste stage (theorie).

Bewijs:

code:

gcc -v bla.c
[...]
GNU C version 4.0.3 (Gentoo 4.0.3, pie-8.7.8) (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.3 (Gentoo 4.0.3, pie-8.7.8).

Dus ook bij gentoo geen uitzonderingen: native compilers worden gewoon in drie stages gebuild en de derde is je nieuwe native compiler gebouwd door zichzelf, door zichzelf gebouwd.

Voor cross-compilers is dat een ander verhaal (duh):

code:

/usr/local/crosscompile/bin/arm-unknown-linux-gnu-gcc -v main.c
GNU C version 4.0.2 (arm-unknown-linux-gnu)
        compiled by GNU C version 4.1.0 (Gentoo 4.1.0).

deepbass909 schreef op zondag 26 maart 2006 @ 20:10:
ARGH!!!

ARGH!?? ~arch bedoel je! Sorry, dit is stomme Gentoo humor.

Veel van de nieuwe pakketten hebben als use-flag een gele flag met een % erachter

Betrapt, je zit op unstable, de laatste stabiele portage gerbuikt die gele %'s niet. Met unstable heb je snel leipe problemen. Zoals een gentoolkit die niet met de nieuwe portage om kan gaan!

offtopic:
Ik gebruik nog steeds portage-2.0.54 ondanks een depend van Xorg-7.0 op een nieuwere portage (die zul je dus indirect hebben met je XGL experimenten). Het mag duidelijk zijn dat deze depend op portage niet helemaal terecht is. Ik ben dus handmatig aan het masken, unmasken en providen. Ik heb namelijk wel zin in een instabiele KDE, XORG, GCC en GLIBC, maar ik voel me niet geroepen algemene Gentoo testdummy te spelen.

~arch levert vaak problemen op. De oorzaak van het een en ander is hier te vinden.

Wat betreft de snelheidswinst, die kan op mijn laptop toch wel merkbaar zijn, aangezien hij maar een 4200rpm schijfje heeft en ik al meerdere keren heb ondervonden dat de harddisk z'n prestaties drukte. En size optimized compilatie heeft voor mij dus wel degelijk nut.

Helemaal mee eens. Je zult bij size-optimalisatie echt wel prestatie verschil kunnen maken, zelfs positief aangezien de vereiste I/O voor het starten van applicaties kleiner wordt.
Opnieuw zou ik ter discussie willen stellen wie er beloofd heeft dat -Os stabiel is. Van welke site heb je deze info? Misschien roepen mensen het om het maar getest te krijgen door veel mensen. Ik gebruik heel graag -Os, ik durf het alleen niet.

[ Voor 24% gewijzigd door irondog op 26-03-2006 21:21 ]

[deepbass909]

Ik haal al m'n info van gentoo-wiki.org en gentoo.org. Ik weet niet precies waar ik welke optie vandaan heb, maar tot op heden werkte het opzich goed.

Wat betref de unstable packages, ik heb er nogal een aantal draaien ivm m'n wifi kaart (vereist wpa_supplicant 0.5.1), KDE 3.4 split ebuild, Xorg 7 (nodig voor Xgl), Xgl, Compiz, Ati.

Het typische dat in m'n package.unmask geen van de probleem pakketten staan, hooguit in de package.keywords. Maar er zijn een aantal die niet gemaskt zijn en toch problemen geven.

Ik ben wel benieuwd hoe je ervoor zorgt dat portage bijvoorbeeld niet naar unstable geupdate hoeft te worden.

ps. ARGH!!! was een kreet van wanhoop. Elke keer als ik dacht dat ik het gefixt had, kwam portage na een kwartier tot half uur na het starten weer met een fout... En om 2 uur 's nachts (je moet er even 6 uur bij tellen omdat ik momenteel in Singapore zit) begint dat redelijk frustrerend te werken...

edit:

overigens lijkt er nu wel schot in de zaak te komen. Ik heb nog wat problemen met aRTSd, maar die moet nog opnieuw gecompileerd worden. Helaas moet ik nog even wachten voor ik weet of het allemaal succesvol is, want hij is nu met pakket 13 van 549 bezig... (ik wou het vannacht laten draaien maar als gevolg van het update werkt m'n wifikaart tijdelijk niet, en die heb ik thuis nodig voor downloaden...)

edit:

Ik heb m'n lijst flink weten te verkorten. Er stond nog een volledige install van KDE 3.4 op
Aangezien KDE 3.5 toch wel heel goed werkt, mag die wel weg

[ Voor 28% gewijzigd door deepbass909 op 27-03-2006 14:12 ]

[deepbass909]

Inmiddels is bijna m'n hele systeem klaar met upgraden, alleen loop ik tegen een groepje erg eigenwijze programma's aan... Het betreft de volledige install van Gnome, die erop staat voor mijn experimenten met Xgl.

code:

x11-drivers/ati-drivers-8.23.7
gnome-base/libbonoboui-2.10.1-r1
gnome-base/libgnomeui-2.12.0
gnome-base/gnome-desktop-2.12.3
gnome-base/librsvg-2.12.7
gnome-base/nautilus-2.12.2
app-admin/gnome-system-tools-1.4.1
app-editors/gedit-2.12.1
app-text/evince-0.4.0-r3
gnome-base/control-center-2.12.3
gnome-base/gdm-2.8.0.7
gnome-base/gnome-panel-2.12.3
gnome-base/gnome-session-2.12.0
gnome-extra/gcalctool-5.6.31
gnome-extra/gconf-editor-2.12.1
gnome-extra/gnome-games-2.12.3
gnome-extra/gnome-keyring-manager-2.12.0
gnome-extra/nautilus-cd-burner-2.12.3
gnome-extra/gnome-media-2.12.0
gnome-extra/gucharmap-1.4.4
gnome-extra/yelp-2.12.2
media-libs/win32codecs-20050412
media-sound/grip-3.3.0
media-video/mpeg2vidcodec-12-r1
media-video/totem-1.2.1
net-analyzer/gnome-netstatus-2.12.0
net-analyzer/gnome-nettool-1.4.1
net-misc/nxclient-1.4.0-r5
net-misc/vino-2.12.0
net-p2p/overnet-1.3.0
www-client/epiphany-1.8.4.1
x11-terms/gnome-terminal-2.12.0

Een aantal ervan blijven terug komen, maar dat zijn voornamelijk binary-gebasseerde pakketten (zoals overnet en de ati-drivers, of eigenlijk alles wat geen deel uitmaakt van een basis Gnome install). Echter stopt elke gnome pakket met de volgende fout:

code:

 /usr/lib/libgnome-2.so /usr/lib/libesd.so /usr/lib/libaudiofile.so /usr/lib/libasound.so /usr/lib/libart_lgpl_2.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so -lpng12 /usr/lib/libglitz.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so /usr/lib/libgnomevfs-2.so /usr/lib/libxml2.so -lz -lssl -lcrypto -lresolv -lrt /usr/lib/libbonobo-2.so /usr/lib/libgconf-2.so /usr/lib/libbonobo-activation.so /usr/lib/libORBitCosNaming-2.so /usr/lib/libORBit-2.so /usr/lib/libpopt.so /usr/lib/libgobject-2.0.so -lm /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libglib-2.0.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libXcursor.so /usr/lib/libXrender.so /usr/lib/libXfixes.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -ldl
/usr/lib/libcairo.so: undefined reference to `__popcountsi2@GCC_3.4'
collect2: ld returned 1 exit status
make[3]: *** [gnome-theme-test] Fout 1
make[3]: Leaving directory `/var/tmp/portage/control-center-2.12.3/work/control-center-2.12.3/capplets/common'
make[2]: *** [all-recursive] Fout 1
make[2]: Leaving directory `/var/tmp/portage/control-center-2.12.3/work/control-center-2.12.3/capplets'
make[1]: *** [all-recursive] Fout 1
make[1]: Leaving directory `/var/tmp/portage/control-center-2.12.3/work/control-center-2.12.3'
make: *** [all] Fout 2

!!! ERROR: gnome-base/control-center-2.12.3 failed.
Call stack:
  ebuild.sh, line 1526:   Called dyn_compile
  ebuild.sh, line 923:   Called src_compile
  ebuild.sh, line 1236:   Called gnome2_src_compile
  gnome2.eclass, line 56:   Called die

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

Ik zie dat de laatste aangeroepen library Cairo betreft, een onderdeel van Gnome + Xgl. Deze heb ik ook opnieuw gecompileerd (zonder foutmelding).

Weet iemand hoe ik dit moet fixen?

[irondog]

Alle relevante packages eerst re-emergen.

code:

#!/bin/sh

LIST="/usr/lib/libgnome-2.so /usr/lib/libesd.so /usr/lib/libaudiofile.so /usr/lib/libasound.so /usr/lib/libart_lgpl_2.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libglitz.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so /usr/lib/libgnomevfs-2.so /usr/lib/libxml2.so /usr/lib/libbonobo-2.so /usr/lib/libgconf-2.so /usr/lib/libbonobo-activation.so /usr/lib/libORBitCosNaming-2.so /usr/lib/libORBit-2.so /usr/lib/libpopt.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libXcursor.so /usr/lib/libXrender.so /usr/lib/libXfixes.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so"

packlist=""
for i in $LIST; do
        pack=""
        pack=$(equery belongs $i | head -n 1)
        if [ -z $pack ]; then
                echo "$i is not installed ??"
        else
                packlist="$MYLIST =${pack}"
        fi
done

emerge --oneshot --nodeps -av $packlist

[deepbass909]

Dat shell scriptje ziet er interessant uit, waar heb je dat vandaan, of is het (c) irondog?

Helaas, hij heeft 1 lib geupdate, maar mc weigerd nog steeds te compileren... Hij blijft hier stoppen:

code:

../vfs/libvfs-mc.a(smbfs.o): In function `loaddir_helper':
smbfs.c:(.text+0xd9f): undefined reference to `LocalTime'
../vfs/libvfs-mc.a(smbfs.o): In function `smbfs_get_path':
smbfs.c:(.text+0x264b): undefined reference to `write_socket'
collect2: ld gaf exit-status 1 terug
make[2]: *** [mc] Fout 1
make[2]: *** Wachten op onafgeronde taken...
make[2]: Leaving directory `/var/tmp/portage/mc-4.6.0-r14/work/mc-4.6.0/src'
make[1]: *** [all-recursive] Fout 1
make[1]: Leaving directory `/var/tmp/portage/mc-4.6.0-r14/work/mc-4.6.0'
make: *** [all] Fout 2

!!! ERROR: app-misc/mc-4.6.0-r14 failed.
Call stack:
  ebuild.sh, line 1526:   Called dyn_compile
  ebuild.sh, line 923:   Called src_compile
  mc-4.6.0-r14.ebuild, line 109:   Called die

[ Voor 83% gewijzigd door deepbass909 op 30-03-2006 14:41 ]

[irondog]

deepbass909 schreef op donderdag 30 maart 2006 @ 11:47:
Dat shell scriptje ziet er interessant uit, waar heb je dat vandaan, of is het (c) irondog?

Dit bevat de commando's die ik zou gebruiken als ik in jouw situatie zat, hier geef ik het in scriptvorm voor de bruikbaarheid voor jou.

Helaas, hij heeft 1 lib geupdate, maar mc weigerd nog steeds te compileren... Hij blijft hier stoppen:[...]

Die undefined reference naar die samba dingen zou ik even laten voor wat het is. Haal anders samba uit je useflags totdat je systeem weer wat gezonder is (is de tweede keer dat ik dat aanbeveel volgens mij). Die undefined reference __popcountsi2@GCC_3.4 zou mij meer zorgen baren. Daarom zou ik de dingen waar gnome tegen linkt maar eens goed opschonen.


Gentoo forums:

quote: darXider

I just emerged gnome 2.14 and everything compiles and runs except nautilus. I have gcc-3.4.5. Does anybody have the same problem as I have? This is the last few lines of the error message that I get:

code:

/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../../i686-pc-linux-gnu/bin/ld: .libs/nautilus: hidden symbol `__popcountsi2' in /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc.a(_popcountsi2.oS) is referenced by DSO
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[4]: *** [nautilus] Error 1
make[4]: Leaving directory `/var/tmp/portage/nautilus-2.14.0/work/nautilus-2.14.0/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/var/tmp/portage/nautilus-2.14.0/work/nautilus-2.14.0/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/nautilus-2.14.0/work/nautilus-2.14.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/nautilus-2.14.0/work/nautilus-2.14.0'
make: *** [all] Error 2

!!! ERROR: gnome-base/nautilus-2.14.0 failed.
Call stack:
  ebuild.sh, line 1565:   Called dyn_compile
  ebuild.sh, line 974:   Called src_compile
  ebuild.sh, line 1280:   Called gnome2_src_compile

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

OK I found that the problem was eith the unstable cairo package that I installed for Xgl.

Cairo lijkt me de boosdoener. De fout van hem bevat ook die akelige undefined reference to _popcountsi2.

edit:

Oja. Het script mag uiteraard nooit dit zeggen: "is not installed??" Dit zou betekenen dat portage niet tidy genoeg is geweest en jij files hebt die niet zouden mogen bestaan. Aangezien jij unstable portage draait........

[ Voor 6% gewijzigd door irondog op 30-03-2006 17:54 ]

[deepbass909]

Op zich werkt alles weer lekker en stabiel, op mc na. Ik heb hem tijdelijk uit m'n worldfile gehaald (ja ik weet wat ik doe) zodat ik tenminste dingen als een systeemupdate kan draaien. Daarnaast heb ik gnome en cairo er weer afgehaald (gnome stond er alleen op voor Xgl, normaal draai ik KDE).

De fout "is not installed??" komt bij mij niet te voorschijn. Op zich draait de laatste portage wel goed. Tot nog toe liggen alleen mc en gnome dwars (en daar heb ik op een andere pc ook al eens problemen mee gehad...)

Trouwens respect dat jij bij gentoo forums dit bovenwater hebt gekregen... ik heb al meerdere pogingen gedaan met de search engine, met verschillende delen van de foutmelding, maar ik kreeg er geen oplossing uit... (dat forum is misschien wel de slechtste zoekmachine die ik in een forem ben tegengekomen...)

Oh ja, om je een beetje gerust te stellen, Irondog, ik heb m'n optimalisatie veranderd in -O2 (de standaard in de installatie handleiding).

[deepbass909]

Ik heb MC gecompileerd zonder de samba USE-vlag en dat gaat wel goed. Het is dus de duidelijk de afhankelijkheid naar Samba die het veroorzaakt. Nu is alleen de vraag waar de fout precies vandaan komt. Samba is met gcc-3.4.5 gecompileerd. Ik vermoed zelf een pakket waar samba zelf weer een dependency mee heeft, maar als ik met equery g samba doe, krijg ik een lijst van 170 pakketten...

[viper]

irondog schreef op zondag 26 maart 2006 @ 18:02:


[...]
De hd is meestal de bottleneck in het gevoel voor snelheid van een systeem. Als Os echt zijn werk goed doet, win je vette snelheid bij in opstarttijden van applicaties.

Uh. Volgens mij is het opstarten van de applicatie niet zozeer het probleem. Dat hoeft immers maar 1x te gebeuren of de harde schijf na 1 of 10 kb moet lezen van die plek voor een binary zal in mijn mening niet heel veel uit maken.
Dat de HD de bottle neck is klopt. Maar een harde schijf is alleen maar nodig indien er geswapt dient te worden. Swappen is alleen nodig als er meer geheugen nodig is dan fysiek aanwezig is in het systeem. Er is alleen maar veel geheugen nodig als programma's 'groter' zijn.
Misschien nog wel het belangrijkste voordeel in mijn mening van de Os flag is programma's kleiner zijn, daardoor wellicht in de processor cache passen en daardoor sneller kunnen lopen...

[deepbass909]

Ik heb mijn probleem inmiddels met MC ook opgelost. Er blijkt een bug in de ebuild te zitten die alleen boven water komt bij gcc-3.4.5
Er is inmiddels een nieuwe versie van MC uit (4.6.1) die wel compileerd met Samba.

Wat mij betreft zijn m'n problemen voorbij er werkt alles zoals het hoort (al is m'n laptop nog wel steeds aan het compileren... maar dat is ook een beetje mijn schuld...)

[webfreakz.nl]

Heb je dit allemaal op je laptop gedaan? En nog distcc gebruikt?

[deepbass909]

nee, geen distcc, alles is op de machine gecompileerd waar ik het op draai (ik heb hier maar de beschikking over 1 (linux) machine.
Alleen als ik had geweten dat het me een week bijna continu compileren had gekost, had ik het nooit gedaan. Door mijn problemen heb ik emerge -e system tot 3 keer opnieuw moeten starten...
Maar straks is alles wel met dezelfde compiler en settings gebouwd, dus moet ik optimale snelheid kunnen halen... (alleen OpenOffice is een binairy install omdat anders mijn experimenten met taal instellingen iets te lang zouden gaan duren...)

[webfreakz.nl]

Een week?
Dan had ik dus toch echt wel Distcc gebruikt! Zal vast ook wel kunnen om die te gebruiken met een computer thuis (aangezien je nu in Singapore zit ).

[deepbass909]

tja, maar die computer thuis is een Celeron 333MHz servertje die met het zelfde bezig is (ook die is inmiddels een week bezig vanwege hetzelfde geintje...)

Maar zoals ik al zei duurt het vooral zo lang door wat foutjes die ik heb gemaakt waardoor ik opnieuw moest beginnen... En een emerge -e world met 500+ pakketten duurt even...