# [gelöst] @world: Chromium 63.0.3239.108 bricht ab

## LuxJux

Nach gefühlten 3 Stunden bricht die Compilierung ab.

Die installierte Version ist: Version 63.0.3239.84 (Entwickler-Build) (64-Bit)

Hier und Hier (sorry, out of english) gibts einen ähnlichen Fehler

```

.

.

.

/src/include -I../../third_party/libwebm/source -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/encode -I../../third_party/skia/include/gpu -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/third_party/vulkan -I../../third_party/skia/src/gpu -I../../third_party/skia/src/sksl -Igen -I../../third_party/WebKit -Igen/third_party/WebKit -I../../v8/include -Igen/v8/include -I../../third_party/WebKit/Source -I../../third_party/WebKit -Igen/blink -Igen/third_party/WebKit -I../../third_party/webrtc_overrides -I../../testing/gtest/include -I../../third_party/webrtc -I../../third_party/webrtc_overrides -I../../third_party/webrtc -I../../third_party/mesa/src/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -g0 -fvisibility=hidden -std=gnu++14 -Wno-narrowing -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -O2 -march=native -pipe -fno-delete-null-pointer-checks -c ../../content/public/browser/gpu_utils.cc -o obj/content/public/browser/browser_sources/gpu_utils.o

ninja: build stopped: subcommand failed.

 * ERROR: www-client/chromium-63.0.3239.108::gentoo failed (compile phase):

 *   ninja -v -j5 -l0 -C out/Release chrome chromedriver failed

 * 

 * Call stack:

 *     ebuild.sh, line  124:  Called src_compile

 *   environment, line 5208:  Called eninja '-C' 'out/Release' 'chrome' 'chromedriver'

 *   environment, line 1790:  Called die

 * The specific snippet of code:

 *       "$@" || die "${nonfatal_args[@]}" "${*} failed"

 * 

 * If you need support, post the output of `emerge --info '=www-client/chromium-63.0.3239.108::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=www-client/chromium-63.0.3239.108::gentoo'`.

 * 

 * MemTotal:        8134444 kB

 * SwapTotal:             0 kB

 * 

 * The complete build log is located at '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/environment'.

 * Working directory: '/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108'

 * S: '/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108'

>>> Failed to emerge www-client/chromium-63.0.3239.108, Log file:

>>>  '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/build.log'

 * Messages for package media-libs/mesa-17.2.7:

 * USE="bindist" was not set. Potentially patent encumbered code was

 * enabled. Please see patents.txt for an explanation.

 * Messages for package www-client/chromium-63.0.3239.108:

 *   USER_NS is required for sandbox to work

 *   CONFIG_COMPAT_VDSO causes segfaults (bug #556286)

 * Please check to make sure these options are set correctly.

 * Failure to do so may cause unexpected problems.

 * ERROR: www-client/chromium-63.0.3239.108::gentoo failed (compile phase):

 *   ninja -v -j5 -l0 -C out/Release chrome chromedriver failed

 * 

 * Call stack:

 *     ebuild.sh, line  124:  Called src_compile

 *   environment, line 5208:  Called eninja '-C' 'out/Release' 'chrome' 'chromedriver'

 *   environment, line 1790:  Called die

 * The specific snippet of code:

 *       "$@" || die "${nonfatal_args[@]}" "${*} failed"

 * 

 * If you need support, post the output of `emerge --info '=www-client/chromium-63.0.3239.108::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=www-client/chromium-63.0.3239.108::gentoo'`.

 * The complete build log is located at '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/environment'.

 * Working directory: '/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108'

 * S: '/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108'

 * 

 * The following package has failed to build, install, or execute postinst:

 * 

 *  (www-client/chromium-63.0.3239.108:0/0::gentoo, ebuild scheduled for merge), Log file:

 *   '/var/tmp/portage/www-client/chromium-63.0.3239.108/temp/build.log'

 * 

 * GNU info directory index is up-to-date.

 * After world updates, it is important to remove obsolete packages with

 * emerge --depclean. Refer to `man emerge` for more information.

```

Prozessor: I5-Quadcore

RAM:       8 Giga

SWAP:     16 Giga

Home "/"         80 Giga free

gcc:     6.4

 *Quote:*   

> [200/363] x86_64-pc-linux-gnu-g++ -MMD -MF base/posix/safe_strerror.o.d  -I/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108/out_bootstrap/gen -I/var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108 -O2 -march=native -pipe -DNO_TCMALLOC -D__STDC_FORMAT_MACROS -O2 -g0 -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -pthread -pipe -fno-exceptions -O2 -march=native -pipe -fno-delete-null-pointer-checks -std=c++14 -Wno-c++11-narrowing -c /var/tmp/portage/www-client/chromium-63.0.3239.108/work/chromium-63.0.3239.108/base/posix/safe_strerror.cc -o base/posix/safe_strerror.o

 

Mehr error wird nicht gefunden im build.log. Ist jedoch kein Fehler sondern Programmcode.

```
 * Messages for package media-libs/mesa-17.2.7:

 * USE="bindist" was not set. Potentially patent encumbered code was

 * enabled. Please see patents.txt for an explanation.
```

 was richtig ist, da ich dies für Wine "use"="-bindist d3d9" benötige.

 P.S.: Profil17-Update wurde mit 

```
emerge -euavDN --with-bdeps=y @world
```

 korrekt abgeschlossen. (ohne backtrace oder keep-going)

--------------------

Edit: emerge --depclean 

findet nur "gentoo-sources 4.12.12"Last edited by LuxJux on Sun Dec 24, 2017 10:01 pm; edited 1 time in total

----------

## ChrisJumper

Hi LuxJux,

ich hab bei mir mal das Update angeworfen um zu schauen ob es bei mir durchläuft oder auch fehl schlägt. Aber ohne den selben Fehler reproduzieren zu können, kann ich dir da nicht helfen.

Aus dem was du gepostet hast sieht man ja quasi nur: ninja: build stopped: subcommand failed.

Es hilft auch nicht via grep lediglich nach "error" zu suchen.

Am besten schaust du in deinem Build Log genau nach: /var/tmp/portage/www-client/chromium-63.0.3239.108/temp/build.log, da dort die Ausgabe des Compiliervorgangs ja fest gehalten wird.

Dadurch das verschiedene Bereiche parallel ablaufen ist es nicht mehr unbedingt die letzte Ausgabe in diesem Log die den Fehler zeigt. Das Ganze läuft ja meist in Blöcken durch. Mittlerweile wird da auch immer diese Nummer angezeigt. Hier ein Beispiel:

 *Quote:*   

> [106/14210] x86_64-pc-linux-gnu-g++ -MMD -MF obj/base/base/file_descriptor_shuffle.o.d -DUSE_SYMBOLIZE -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBASE_IMPLEMENTATION -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -I../.. -Igen -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -fomit-frame-pointer -g0 -fvisibility=hidden -O2 -fno-ident -fdata-sections -ffunction-sections -s ....

 

Rot ist da quasi die Block-Nummer. Hier Nummer 106 von 14210. Das Variiert eventuell nach den Einstellungen deines Systems und kommt von Autoconf oder bestimmte Bereiche des Browsers werden in mehreren Abschnitten unterteilt. Hier ist Chromium auch nicht fertig nach den 14210, sondern im Anschluss gibt es immer noch eine weitere Etappe mit einer unterschiedlichen Anzahl an Blocken.

Grün ist ja quasi der Compiler-Befehl danach folgen Parameter mit denen der Compiler startet. -D steht für Definition, hier werden diverse Variablen gesetzt die der Compiler berücksichtigt. Quasi das was deine Autoconf ergeben hat oder welche Useflags du gesetzt hast, damit der Compiler-Vorgang das bei dem bauen der Binärdatei berücksichtigt.

Blau sind dann -I, das steht für Include und gibt an welche Verzeichnisse der Compiler auf der Suche nach Header-Dateien durchsucht.

Die -W sind Warning Einstellungen die halt das Verhalten des Compilers betreffen.

Ganz am Ende eines Compilerblocks findet sich meist in der Regel ein -o flag das Angibt welche Datei zusammen gebaut wurde. Z.b.:  -checks -c ../../net/socket/ssl_client_socket.cc -o obj/net/net/ssl_client_socket.o

Wenn du jetzt einen Fehler suchst steht er meist hinter diesen Blöcken. Wie bei einem Programm das du von der Kommandozeile starten willst und sich beschwert das ein Parameter falsch war.

Dadurch das mehrere Threads beim Compilieren aber parallel arbeiten kann das sein das du den Fehler nicht direkt am Ende findest sondern dazwischen noch einige Blöcke sind die funktioniert haben. Hängt auch davon ab wie viel Kerne dein System hat und wie viele du davon gleichzeitig nutzt um das Compilieren zu beschleunigen, oder der aktuellen Situation.

Stell dir vor du baust ein Lego-Projekt und Freunde helfen dir, jeder nimmt sich einen Teil der Anleitung vor und du delegierst den Bauauftrag an die Freunde, zum Schluss gibt dir jeder halt eine Teil-Ergebnis und du musst die zusammen stecken. Je nachdem ob und wo einem deiner Freunde ein Fehler unterlaufen ist, findet er sich nicht unbedingt direkt dort wo er aufgetreten ist.

Letztlich schreibt jeder aber seine Arbeitsschritte in den Log und da findet man dann die Erfolge und Fehler. Für den genauen Fehler der bei dir zum Compiler-Abbruch geführt hast musst du quasi zwischen diesen Blöcken lesen. Je nachdem stehen da auch Compilerwarnungen zwischen, diese Warnungen müssen aber nicht zwangsläufig mit dem Abbruch zusammen hängen, können manchmal aber ein Hinweis sein.

----------

## LuxJux

Hallo Chris

Ganz, ganz herzlichen Dank für deine ausführliche Antwort. (Allerdings werde ich darüber wohl noch etwas meditieren müssen, bis ich das verstanden hab)

Und ein   :Idea: 

Hatte doch gestern glatt vergessen, den USB-Stick zu entfernen, weshalb ich heute die Live-CD bootete. Und keine Zeit wegen Heiligabend.

Keinen Browser, keine Programme. Nur die Konsole geöffnet und chrootet

Lief sauber durch. 

Möglicherweise lag es tatsächlich an einem <Out of memory> Error

----------

## ChrisJumper

Ja kann sein, aber du hattest wirklich viel swap. :D

Mein Test-Update klappte zumindest ohne Probleme.

Bin aktuell ziemlich erkältet und deswegen wohl ein wenig wirr. Eigentlich wollte ich nur schreiben das Compilerfehler wenn sie denn auftreten dir immer einen genauen hinweis geben, der aber oft etwas weiter oben steht im build.log

Dann hab ich versucht diese einzelnen Ausgaben des Compilers über Blöcke/Schritte zu veranschaulichen. Wenn man darauf achtet kann man quasi die Zeilen-Ausgaben ausmachen, die so ein Emerge-Vorgang oder Compiler-Vorgang erzeugt.

Das blöde ist nur das eine Zeile nicht einer Zeile in der Shell-Ausgabe entspricht weil diese unheimlich lang sind. Aber im Grunde fängt sie so an wie meine Block-Beschreibung da oben. Mit dieser Nummer und dann dem Compiler "x86_64-pc-linux-gnu-g++" und dem ganzen kram dahinter.

Vielleicht hattest du zuvor vergessen dein Swap ins System einzuhängen und deswegen war nach 8GB RAM Schluss. Hier hat mein System auch nur 8 gb und noch 1,3 GB ausgelagert als es den Compiler lauf gestartet hatte.

So bin dann mal wieder zur Party, frohes Weihnachtsfest an alle die das jetzt lesen!

----------

## LuxJux

 *ChrisJumper wrote:*   

> Vielleicht hattest du zuvor vergessen dein Swap ins System einzuhängen und .....

 

Beim Starten erhalte ich eigentlich nur die Fehlermeldung, daß die HW-Clock=Fehler, nicht richtig ist.

Doch das kann ich kognitiv -1 Stunde runterrechnen. (Warte erstmal ab, bis die Sommerzeit kommt)

Besteht denn die Möglichkeit, einen TestSchreib auf die SWAP auszuführen ?

----------

## LuxJux

 *ChrisJumper wrote:*   

> Ja kann sein, aber du hattest wirklich viel swap. 

 

Dabei dachte meiner einer immer <gentoo> wär sicher.

----------

