# [solved]Fehler über Fehler... Und Wünsche ;)

## Mr_Maniac

Hallo zusammen!

Nun... Erst einmal zu etwas, dass mich schon länger beschäftigt...

Wenn man "normal" etwas kompiliert (ohne emerge) und irgendwann mittendrin abbricht (oder es tritt ein Fehler auf), dann wird ja meistens beim nächsten Aufruf von "make" an der Stelle fortgesetzt, wo abgebrochen wurde...

Wäre es nicht schön, wenn emerge das auch so machen könnte?

Die Option "--resume" fährt ja nur ab dem Programm fort, dass abgebrochen wurde... Dieses wird dann nochmal komplett von Anfang bis zum Ende kompiliert...

Bei großen Paketen ist das schon sehr ärgerlich, weil es eventuell Stunden dauern kann, bis man wieder an die Stelle kommt, wo vorher der Fehler auftrat!

Und nun noch etwas:

Bei mir schlägt das emergen von bestimmten Paketen immer fehl...

Ich habe schon viele Sachen re-emerged um zu sehen, ob es was bringt, aber es hilft alles nichts...

Drei Pakete, die sich nicht emergen oder updaten lassen:

swig-1.3.21

libcap-1.10-r5

net-tools-1.60-r11

Die Fehlerausgaben findet ihr HIER

Auch das "m4" Paket hatte Probleme mit dem kompilieren...

Dort stand etwas mit "siginfo.h"... Diese Datei konnte nicht kompiliert werden...

Ich hatte mal zum Test die angezeigte Datei und die Datei "resource.h" gesichert und durch die Dateien aus meinem "/usr/src/linux/include/asm-i386(und generic)" Verzeichniss ersetzt und siehe da, wenigstens dieses Paket konnte upgedated werden... Sehr seltsam  :Shocked: 

Hier noch der output von emerge --info:

 *Quote:*   

> 
> 
> Gentoo Base System version 1.4.16
> 
> Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r4 i686)
> ...

 

----------

## pablo_supertux

 *Mr_Maniac wrote:*   

> Hallo zusammen!
> 
> Nun... Erst einmal zu etwas, dass mich schon länger beschäftigt...
> 
> Wenn man "normal" etwas kompiliert (ohne emerge) und irgendwann mittendrin abbricht (oder es tritt ein Fehler auf), dann wird ja meistens beim nächsten Aufruf von "make" an der Stelle fortgesetzt, wo abgebrochen wurde...
> ...

 

füge keepwork in die FEATURES Variable (/etc/make.conf) hinzu

----------

## oscarwild

 *Mr_Maniac wrote:*   

> Wenn man "normal" etwas kompiliert (ohne emerge) und irgendwann mittendrin abbricht (oder es tritt ein Fehler auf), dann wird ja meistens beim nächsten Aufruf von "make" an der Stelle fortgesetzt, wo abgebrochen wurde...

 

Das stimmt so nicht ganz. Make vergleicht die Timestamps der zu generierenden Dateien mit den Timestamps der Quelldateien, aus denen das Ziel erstellt wird. Ist mindestens eine Quelldatei neuer als das Ziel, wird das Ziel neu erstellt. Das ganze Prozedere klappt allerdings nur, wenn die Abhängigkeiten im Makefile konsequent und fehlerfrei eingerichtet wurden.

Dieses Vopprgehen ist immer dann sinnvoll, wenn bei der Entwicklung Teile des Quellcodes geändert werden.

 *Mr_Maniac wrote:*   

> Die Option "--resume" fährt ja nur ab dem Programm fort, dass abgebrochen wurde... Dieses wird dann nochmal komplett von Anfang bis zum Ende kompiliert... 

 

Es wäre sinnlos, das Paket unter den selben Umgebungsbedingungen mehrmals zu compilieren, in der Hoffnung, dass es beim n-ten Versuch dann auf einmal geht. Man wird entweder an den Useflags drehen, benachbarte Pakete neu installieren, den Kernel ändern etc., und dann nochmal sein Glück versuchen. Für diese geänderten Umgebungsbedingungen wäre Make alleine u.U. blind.

Wirf mal einen Blick auf ccache. Das ist ein Compilercache, der bereits übersetzte Fragmente wiederverwendet, und gerade solche Fälle stark beschleunigen kann.

----------

## Mr_Maniac

 *pablo_supertux wrote:*   

> 
> 
> füge keepwork in die FEATURES Variable (/etc/rc.conf) hinzu

 

Nicht in die make.conf?

 *oscarwild wrote:*   

> Wirf mal einen Blick auf ccache. Das ist ein Compilercache, der bereits übersetzte Fragmente wiederverwendet, und gerade solche Fälle stark beschleunigen kann.

 

Ich dachte, dass wäre seit einiger Zeit standardmäßig aktiviert...

Steht bei emerge --info auch in den FEATURES drinnen:

 *Quote:*   

> FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" 

 

EDIT:

Okay... ccache stand zwar in den Features, war aber noch nicht installiert...

EDIT2:

Okay... swig und libcap konnte ich nach längerem Probieren auch endlich emergen...

Ich musste lediglich ein "USE=-tcltk emerge swig" machen... Danach hat auch libcap geklappt...

Was allerdings mit net-tools, kdemultimedia, transcode und noch so einigen Sachen los ist, weiss ich immernoch nicht...

----------

## pablo_supertux

 *Mr_Maniac wrote:*   

>  *pablo_supertux wrote:*   
> 
> füge keepwork in die FEATURES Variable (/etc/rc.conf) hinzu 
> 
> Nicht in die make.conf?

 

ach ja stimmt, make.conf. Sorry, mein Fehler.

----------

## Mr_Maniac

Status-Update:

Ich habe nun einiges wieder zum Laufen gebracht...

Nun kämpfe ich mit dem Problem, dass GCC das "Branch-Update" mit an seine Versionsnummer dranhängt (3.4.3-20050110)...

Viele Programme haben damit Probleme  :Mad: 

----------

## Mr_Maniac

Ich habe mal wieder eine kleine, aber feine Frage:

Ich habe gerade bemerkt, dass sich das gcc von meinem kleinen Router/Server mit "3.4.3" meldet, OBWOHL es GENAU die gleiche Version ist, wie gcc auf meinem Haupt-PC...

Nämlich "3.4.3-20050110"...

Nur meldet mein PC auch "3.4.3-20050110", was einige Programme verwirrt (z.B. OpenOffice und MPlayer, diese wollen deshalb nämlich nicht mehr kompilieren...).

Was kann ich tun, damit sich "mein" gcc wieder normal mit "3.4.3" meldet?

re-emerged habe ich es die letzten Tage schon mehrere Male... Ich werde es aber gleich noch einmal probieren...

Danke schonmal für die Hilfe!

EDIT:

Ganz vergessen:

Mein Server/Router hat eine i586 Architektur und mein PC eine i686 Architektur...

EDIT2:

Wo ich vorher bei Wünschen wäre, wollte ich fragen, ob es nicht vielleicht sinnvoll sein könnte, ein dev-stable-flag einzuführen... KA, wie ich das im kurzen ausdrücken sollte, deswegen sage ich es jetzt ein mal im langen:

Es ist ja oft so, dass Programme von den eigentlichen Entwicklern schon lange als stable bezeichnet werden, aber noch nicht so im Portage-Tree behandelt werden...

Wie wäre es da mit einem zusätzlichen Flag, dass das Paket als "in Gentoo unstable aber stable, wenn man auf die Entwicklerseite sieht" maskiert?

----------

## oscarwild

 *Mr_Maniac wrote:*   

> Wie wäre es da mit einem zusätzlichen Flag, dass das Paket als "in Gentoo unstable aber stable, wenn man auf die Entwicklerseite sieht" maskiert?

 

Unstable heisst: unzureichende Testabdeckung in Gentoo. Punkt. Selbst wenn das Paket seit tausend Jahren unter SchiessMichTot-Linux läuft.

Wer unbedingt Software einspielen muss, die noch nicht als stable gekennzeichnet ist, sollte gute Gründe dafür haben, und nimmt in Kauf, dass er damit baden gehen kann. Entweder riskiere ich das einfach auf gut Glück (und beschwere mich hinterher nicht, wenn mein Rechner dann explodiert), oder ich schau mal selber auf die Homepage des entsprechenden Pakets und informiere mich, um das Risiko abzuschätzen.

Unabhängig vom Pflegeaufwand - was sollte man aus einer solchen Information denn konkret ablesen können? Dass man die Kennzeichnung als Gentoo-unstable in dem Fall getrost ignorieren kann, und irgendwer im Forum sich schon finden wird, dem man damit auf den Zeiger gehen darf?

Ohne persönlich werden zu wollen: gcc-3.4.3-20050110 - weshalb? Stable für x86 ist 3.3.5-r1, und Du wunderst Dich, warum Dein System nicht ordentlich compiliert. Der konkrete Anlass, die einzige Version einzusetzten, die auf allen Architekturen noch unstable-Status besitzt, würde mich brennend interessieren.

----------

## Mr_Maniac

 *oscarwild wrote:*   

> Ohne persönlich werden zu wollen: gcc-3.4.3-20050110 - weshalb? Stable für x86 ist 3.3.5-r1, und Du wunderst Dich, warum Dein System nicht ordentlich compiliert. Der konkrete Anlass, die einzige Version einzusetzten, die auf allen Architekturen noch unstable-Status besitzt, würde mich brennend interessieren.

 

Öhm.. Nun ja... Weil es seit letztem Jahr schon ohne Probleme ging?

Weil das anscheinend einzige Problem, dass von GCC her rührt momentan dieses ist, dass es sich dummerweise mit der vollen Versionsnummer (3.4.3.20050110) meldet und damit einige Programme nicht klarkommen?

(Zur Erklärung: Für die Probleme, die ich vorher hatte, musste ich nur einige Pakete neu kompilieren... Oder ein USE-Flag abschalten...)

Wenn wir dabei sind: Warum benutze ich die NEUESTEN nVidia-Treiber (allerdings das Paket von nVidias Web-Seite)?

Vielleicht, weil sie besser funktionieren, als die alten?

Ich habe nichts gegen das Test-System von Gentoo, aber so manche Sachen, die noch als unstable gekennzeichnet sind, kann man tatsächlich ohne Probleme verwenden...

----------

## oscarwild

 *Mr_Maniac wrote:*   

> Wenn wir dabei sind: Warum benutze ich die NEUESTEN nVidia-Treiber (allerdings das Paket von nVidias Web-Seite)? 
> 
>  Vielleicht, weil sie besser funktionieren, als die alten?

 

Das ist ein Argument.

 *Mr_Maniac wrote:*   

> Öhm.. Nun ja... Weil es seit letztem Jahr schon ohne Probleme ging?

 

Das ist KEIN Argument, sondern schlichtweg irrational, es sei denn, Du bist Entwickler, und weißt genau, was Du tust.

 :Arrow:  um Gottes Willen bitte kein "nicht-getestet-aber-wird-schon-passen"-Flag.

----------

## fehlfarbe

Hi,

ich habe mich auch für die "unstable" entschieden. Ich kenne das Risiko, will aber die Vorzüge neuer Versionen nicht missen.

Mein Motto ist: Cool bleiben, wenn was nicht funktioniert...Hinzufügen möchte ich noch, dass die unstable Version seit Jahren relativ zuverlässig (bei mir) läuft - bin wirklich sehr zufrieden damit. Ausserdem wäre bei einem Ausfall meines Desktops kein Leben oder eine Firma in Gefahr...

Gentoo ist doch gerade auch wegen der aktuellen Paketauswahl so lobenswert.

mfg Christian

----------

## pablo_supertux

 *Mr_Maniac wrote:*   

> 
> 
> Vielleicht, weil sie besser funktionieren, als die alten?
> 
> 

 

das ist ein Fall, nicht die Regel, und warum Systeme stabil sind? Weil es eine Gruppe von Entwickerln, die Packete auf stable und testing maskieren und zuerst hart testen, bevor die Packete stable werden.

 *Quote:*   

> 
> 
> Ich habe nichts gegen das Test-System von Gentoo, aber so manche Sachen, die noch als unstable gekennzeichnet sind, kann man tatsächlich ohne Probleme verwenden...
> 
> 

 

niemand schreibt dir vor, dass du nur stable Sachen benutzen sollst, nicht einmal portage zu benutzen schreibt dir jemand vor, also heule nicht rum. Wenn du nicht da stable-setzen der testing Packages warten kannst, setze deine ACCEPT_KEYOWRDS eben auf testing und basta! Aber du darfst dich nicht beschweren, wenn mal was nicht läuft. Anpruch auf Support mit   ~x86 in ACCEPT_KEYOWRDS hast du nicht, weil man davor gewarnt hat.

----------

## psyqil

 *Quote:*   

> Wie wäre es da mit einem zusätzlichen Flag, dass das Paket als "in Gentoo unstable aber stable, wenn man auf die Entwicklerseite sieht" maskiert?

 Gibt's schon, heißt "~". Wenn ein Paket eindeutig explosiv ist, kommt's in die package.mask.

----------

## Tobiking

Also wenn man etwas installiert sollte man grob wissen was es ist und wissen was man damit machen will. Wenn man zusätzliche features haben will die es in einer neuen unstable version gibt (erfährt man auf der entwickler seite) kann man ruhig mal unstable probieren. 

Aber es gibt garantiert immer Gründe für unstable, sei es das zusammenspiel 2er packete oder sonst was. Es gibt ja auch "optionale abhängigkeiten" die portage usw. nicht kennt. Mir fiel auf anhieb ein das xchat-2 z.B. urls im firefox öffnen kann. Eventuell weiß der gentoo zuständige für Firefox das in der neuen version die funktion mit dem neuen firefox prbleme macht und wartet bis der x-chat zusändige da mit aktualisiert obwohl die beiden packete keine abhängigkeit haben. Dient alles dazu damit sich am ende niemand beschwert warum etwas nicht funktioniert  :Very Happy:  .

----------

## TheSmallOne

Wie wird denn eigentlich entschieden, wann ein Paket als stable gekennzeichnet wird?

Lassen die Leute die die ebuilds schreiben das ganze einfach eine Weile laufen und gucken, ob in der Zeit nichts passiert, oder wie?

----------

## lpetersen

So ungefähr. Wobei das Entwicklerhandbuch als groben Anhaltspunkt vorschlägt, einen Monat ohne bestätigten/ungelösten Bug abzuwarten. Letztlich entscheidet das aber allein der verantwortliche Developer. Guckst du hier.

----------

## Mr_Maniac

So... Das meiste ist behoben...

Da waren viele header am falschen Platz (einige sind es immer noch)...

----------

