# [gelöst]Failed to emerge dev-qt/qtwebengine-5.15.2_p20211216

## uhai

Seit ein paar Tagen bekomme ich qtwebenginge nicht mehr emerged:

```
....dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -I/usr/include/nss -I/usr/include/nspr -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -Wno-deprecated-declarations -c ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/browser/renderer_host/frame_tree_node.cc -o obj/content/browser/browser/frame_tree_node.o

ninja: build stopped: subcommand failed.

make[3]: *** [Makefile.gn_run:513: run_ninja] Error 1

make[3]: Leaving directory '/home/uhai/Fotos/portage/dev-qt/qtwebengine-5.15.2_p20211216/work/qtwebengine-5.15.2_p20211216_build/src/core'

make[2]: *** [Makefile:82: sub-gn_run-pro-make_first] Error 2

make[2]: Leaving directory '/home/uhai/Fotos/portage/dev-qt/qtwebengine-5.15.2_p20211216/work/qtwebengine-5.15.2_p20211216_build/src/core'

make[1]: *** [Makefile:78: sub-core-make_first] Error 2

make[1]: Leaving directory '/home/uhai/Fotos/portage/dev-qt/qtwebengine-5.15.2_p20211216/work/qtwebengine-5.15.2_p20211216_build/src'

make: *** [Makefile:49: sub-src-make_first] Error 2

 * ERROR: dev-qt/qtwebengine-5.15.2_p20211216::gentoo failed (compile phase):

 *   emake failed

```

Ich kanns wieder mal nicht alleine lösen... jeder Tipp wird gerne probiert, da mein digikam nso nicht läuft....

emerge --info '=dev-qt/qtwebengine-5.15.2_p20211216::gentoo'

```
emerge --info '=dev-qt/qtwebengine-5.15.2_p20211216::gentoo'

Portage 3.0.30 (python 3.9.9-final-0, default/linux/amd64/17.1/systemd, gcc-11.2.0, glibc-2.33-r7, 5.15.16-gentoo x86_64)

=================================================================

                         System Settings

=================================================================

System uname: Linux-5.15.16-gentoo-x86_64-AMD_FX-tm-8350_Eight-Core_Processor-with-glibc2.33

KiB Mem:    32846544 total,  16654260 free

KiB Swap:     524284 total,    524284 free

Timestamp of repository gentoo: Sat, 12 Feb 2022 16:00:01 +0000

Head commit of repository gentoo: e3e97382faef9ad5f8b9095e37d5e066580c9684

sh bash 5.1_p16

ld GNU ld (Gentoo 2.37_p1 p0) 2.37

app-misc/pax-utils:        1.3.3::gentoo

app-shells/bash:           5.1_p16::gentoo

dev-java/java-config:      2.3.1::gentoo

dev-lang/perl:             5.34.0-r6::gentoo

dev-lang/python:           2.7.18_p13::gentoo, 3.9.9-r1::gentoo, 3.10.0_p1-r1::gentoo

dev-lang/rust:             1.58.1::gentoo

dev-util/cmake:            3.22.2::gentoo

dev-util/meson:            0.60.3::gentoo

sys-apps/baselayout:       2.7-r3::gentoo

sys-apps/sandbox:          2.25::gentoo

sys-apps/systemd:          249.9::gentoo

sys-devel/autoconf:        2.13-r1::gentoo, 2.71-r1::gentoo

sys-devel/automake:        1.13.4-r2::gentoo, 1.16.4::gentoo

sys-devel/binutils:        2.37_p1::gentoo

sys-devel/binutils-config: 5.4::gentoo

sys-devel/clang:           13.0.0::gentoo

sys-devel/gcc:             11.2.0::gentoo

sys-devel/gcc-config:      2.5-r1::gentoo

sys-devel/libtool:         2.4.6-r6::gentoo

sys-devel/lld:             13.0.0::gentoo

sys-devel/llvm:            13.0.0::gentoo

sys-devel/make:            4.3::gentoo

sys-kernel/linux-headers:  5.15-r3::gentoo (virtual/os-headers)

sys-libs/glibc:            2.33-r7::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-verify-jobs: 1

    sync-rsync-extra-opts: 

    sync-rsync-verify-max-age: 24

    sync-rsync-verify-metamanifest: yes

mein-repo

    location: /usr/local/portage

    masters: gentoo

lua

    location: /var/lib/layman/lua

    sync-type: laymansync

    sync-uri: https://anongit.gentoo.org/git/proj/lua.git

    masters: gentoo

    priority: 50

mv

    location: /var/lib/layman/mv

    sync-type: laymansync

    sync-uri: https://anongit.gentoo.org/git/user/mv.git

    masters: gentoo

    priority: 50

waebbl

    location: /var/lib/layman/waebbl

    sync-type: laymansync

    sync-uri: https://github.com/waebbl/waebbl-gentoo.git

    masters: gentoo

    priority: 50

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="@FREE"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=native -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php8.0/ext-active/ /etc/php/cgi-php8.0/ext-active/ /etc/php/cli-php8.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

CXXFLAGS="-march=native -O2 -pipe"

DISTDIR="/usr/portage/distfiles"

ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirror.netcologne.de/gentoo/ ftp://mirror.netcologne.de/gentoo/ rsync://mirror.netcologne.de/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.halifax.rwth-aachen.de/gentoo/ ftp://ftp.halifax.rwth-aachen.de/gentoo/ rsync://ftp.halifax.rwth-aachen.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo rsync://ftp-stud.hs-esslingen.de/gentoo/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/"

LANG="de_DE.utf8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="de_DE de"

MAKEOPTS="-j9"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_TMPDIR="/home/uhai/Fotos"

SHELL="/bin/bash"

USE="X a52 aac acl alsa amd64 bluetooth bzip2 cdda cddb cdr clamav cli crypt cups dga dri dts dvd dvdr exif ffmpeg flac foomaticdb fortran gdbm gif gphoto2 heif iconv icu ipv6 jbig jpeg jpeg2k lcms lensfun libglvnd libtirpc lisp mmx mp3 mp4 mpeg multilib ncurses nls nptl nvidia ocr ogg opengl openmp pam pcre php png qt5 raw readline scanner seccomp split-usr sse sse2 ssl svg systemd tesseract theora threads tiff truetype udev unicode v4l vcd vdpau vim-syntax wayland webp wmf xattr xine xv xvid xvms zlib" ABI_X86="64" ADA_TARGET="gnat_2020" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="bindist mmx sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev libinput wacom" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_9" PYTHON_TARGETS="python3_9" RUBY_TARGETS="ruby 26 ruby 27" SANE_BACKENDS="hp" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LEX, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS

```

```
less /home/uhai/Fotos/portage/dev-qt/qtwebengine-5.15.2_p20211216/temp/environment

declare -x ABI="amd64"

declare -x ABI_MIPS=""

declare -x ABI_PPC=""

declare -x ABI_S390=""

declare -x ABI_X86="64"

declare -x ADA_TARGET=""

declare -x ALSA_CARDS=""

declare -x ANT_HOME="/usr/share/ant"

declare -x APACHE2_MODULES=""

declare -x APACHE2_MPMS=""

declare -x ARCH="amd64"

declare BDEPEND="|| ( >=dev-lang/python-2.7.5-r2:2.7[xml(+)] )

        dev-util/gperf

        dev-util/ninja

        dev-util/re2c

        net-libs/nodejs[ssl]

        sys-devel/bison

        sys-devel/flex

        ppc64? ( >=dev-util/gn-0.1807 )

 

        dev-lang/perl

        virtual/pkgconfig

"

declare -x BOOTSTRAP_USE="unicode internal-glib pkg-config split-usr xml python_targets_python3_9 multilib systemd udev"

declare -x CALLIGRA_FEATURES=""

declare -x CAMERAS=""

declare -x CBUILD="x86_64-pc-linux-gnu"

declare -x CFLAGS="-march=native -O2 -pipe"

declare -x CFLAGS_amd64="-m64"

declare -x CFLAGS_default

declare -x CFLAGS_x32="-mx32"

declare -x CFLAGS_x86="-m32"

declare -x CHOST="x86_64-pc-linux-gnu"

declare -x CHOST_amd64="x86_64-pc-linux-gnu"

declare -x CHOST_default="x86_64-pc-linux-gnu"

declare -x CHOST_x32="x86_64-pc-linux-gnux32"

declare -x CHOST_x86="i686-pc-linux-gnu"

declare -x COLLECTD_PLUGINS=""

declare -x COLORFGBG="15;0"

declare -x CPU_FLAGS_ARM=""

declare -x CPU_FLAGS_PPC=""

declare -x CPU_FLAGS_X86=""

declare -x CTARGET_default="x86_64-pc-linux-gnu"

declare -x CURL_SSL=""

declare -x CXXFLAGS="-march=native -O2 -pipe"

declare -x DEFAULT_ABI="amd64"

declare -x DEFINED_PHASES=" compile configure install postinst postrm preinst prepare pretend setup test unpack"

declare DEPEND="

        app-arch/snappy:=

        dev-libs/glib:2

        dev-libs/nspr

```

uhaiLast edited by uhai on Mon Mar 07, 2022 5:55 pm; edited 3 times in total

----------

## mike155

Wir brauchen das Build Log mit der Fehlermeldung!   :Smile: 

----------

## demiurg

Beliebtestes Thema mit qtwebengine (auch aus eigener Erfahrung) ist Ram-Mangel. 

Aktuell wird bei den Vorchecks geschaut, ob je gesetztem Thread/Kern in der make.conf (MAKEOPTS="-j32") je Thread mind. 2 GB RAM verfügbar sind. Das ist scheint auch unabhängig von der Tatsache zu sein (nicht in allen Varianten durchgetestet), ob im tmpfs compiliert wird oder auf der Platte. Mit 64 GB physischem RAM ist nix mit -j32. -j30 funktioniert. der Vorteil gegenüber -j16 ist nicht so brutal, so dass ich qtwebengine mit den 16 physischen Kernen compiliere und das Temp-Portageverzeichnis auch mit im tmpfs laufen lassen kann. Braucht dann knapp 40 min.

Gruß

demiurg

----------

## uhai

Hier bitte sehr:

http://0x0.st/o8re.log

Sorry, musste erst noch wgetpaste installieren....

uhai

----------

## demiurg

Jedenfalls scheinen mehr als 18 GB Ram installiert zu sein, sonnst hätte es mit dem Check schon einen Halt gegeben. ich habe noch einen interessanten Nebeneffekt. 4 besetzte RAM-Bänke und mit XMP-Profil aktiv auf 3000 MHz eingestellt, schmiert das compilieren auch mit -j16 mit so einem Fehler ab. XMP aus und das ganze läuft durch. Ich würde erstmal die beiden Sachen MAKEOPTS=-j4 probieren und das Thema XMP betrachten.

Gruß

demiurg

----------

## uhai

webkit-gtk-2.34.5 bricht ebenfalls ab:

http://0x0.st/o8r7.log

@demiurg

Hier sind 32 GB installiert. Was meinst Du mit XMP-Profil? Ist das nicht eine Einstellung im BIOS? Da ist seit Kauf nix mehr geändert worden..... Kann ich das irgendwie testen?

uhai

----------

## mike155

Hier ist die Fehlermeldung:

```
[8044/23888] /usr/bin/x86_64-pc-linux-gnu-g++ ... obj/v8/v8_base_without_compiler/v8_base_without_compiler_jumbo_36.o

FAILED: obj/v8/v8_base_without_compiler/v8_base_without_compiler_jumbo_36.o 

In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/string:55,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/locale_classes.h:40,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/ios_base.h:41,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/ios:42,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/ostream:38,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/common/globals.h:12,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/objects/visitors.h:8,

                 from ./../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/objects/visitors.cc:5,

                 from gen/v8/v8_base_without_compiler_jumbo_36.cc:5:

/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/basic_string.h: In function ‘void std::swap(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _A

/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/basic_string.h:6495:25: error: expected ‘;’ before ‘}’ token

 6495 |     { __lhs.swap(__rhs); }

      |                         ^~

      |                         ;

```

Das sieht für mich NICHT nach einem Fehler wegen zu wenig RAM aus...

Da der Fehler etwas mysteriös ist (Google findet nichts, keine Einträge in den Bug-Datenbanken), bin ich über folgende Zeile gestolpert:

```
>>> Compiling source in /home/uhai/Fotos/portage/dev-qt/qtwebengine-5.15.2_p20211216/work/qtwebengine-5.15.2_p20211216 ...
```

Könnte es etwas damit zu tun haben, dass Du das Paket nicht in /var/tmp/portage baust?Last edited by mike155 on Sun Feb 13, 2022 2:01 pm; edited 2 times in total

----------

## arfe

Und wie groß ist Dein Swap?

----------

## arfe

PORTAGE_TMPDIR="/home/uhai/Fotos" 

Und was soll denn der Unsinn?

----------

## uhai

@arfe:

Der Unsinn ist für libreoffice nötig gewesen, weil ich auf diesem Laufwerk genug Platz habe. Deshalb habe ich das verlegt... Swap ist 512 MB... hatte ich größer in Erinnerung, ist aber schon seit Jahren so.

@mike155:

weiß ich nicht, alles andere - außer webkit-gtk lässt sich bauen, schon seit Jahren. 

checking for at least 7GB... also 7 GB sollte ich haben, dann könnte ich die Variable ja mal auskommentieren und Versuchen ob es dann geht - richtig? Auf /var/temp/portage sind noch 8 GB frei... Auf /home/uhai/Fotos sind 52 GB frei.

----------

## arfe

 *uhai wrote:*   

> @arfe:
> 
> Der Unsinn ist für libreoffice nötig gewesen, weil ich auf diesem Laufwerk genug Platz habe. Deshalb habe ich das verlegt... Swap ist 512 MB... hatte ich größer in Erinnerung, ist aber schon seit Jahren so

 

Und Du hältst 512 MB Swap wirklich für Ausreichend wenn er bei solch großen Paketen swappen muss? Vor allem wenn mehrere große Portage Pakete kompiliert werden müssen?

Entweder schraubst Du deine Kerne zurück oder erhöhst Mal Deinen Swap ordentlich. Auch 32 GB RAM können bei sehr großen Paketen sehr schnell voll sein.

Einmal ein emerge -e world und Du bist mit Deinen 512 MB Swap sehr schnell weg vom Fenster.Last edited by arfe on Sun Feb 13, 2022 2:39 pm; edited 1 time in total

----------

## mike155

Meine Erfahrung ist, dass Gentoo um so besser funktioniert, je näher man an den Default-Einstellungen bleibt.

Das heißt nicht, dass man nichts ändern kann, darf oder soll. Aber wenn komische Fehler auftreten, ist es eine gute Strategie für die Fehlersuche, alles rückgängig zu machen, was man an Besonderheiten hat.

@uhai: da Du 32GB RAM Hast, könntest Du ein 12 GB großes tmpfs nach /var/tmp/portage mounten. So mache ich es - ich baue meine Pakete immer im tmpfs. 

```
tmpfs   /var/tmp/portage   tmpfs   size=12G,nodev,nosuid   0   0
```

Auf meinen Maschinen mit weniger RAM nutze ich zram (=tmpfs mit Komprimierung). Man erreicht einen Komprimierungsfaktor von ungefähr 2, aber es wird etwas langsamer.

----------

## arfe

 *mike155 wrote:*   

> 
> 
> @uhai: da Du 32GB RAM Hast, könntest Du ein 12 GB großes tmpfs nach /var/tmp/portage mounten. So mache ich es - ich baue meine Pakete immer im tmpfs. 
> 
> ```
> ...

 

Das ist so gar nicht nötig, wenn man sich hier daran hält und verstanden hat: https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs

Für große Pakete nimmt man notmpfs und für kleinere Pakete /var/tmp/portage im RAM.Last edited by arfe on Sun Feb 13, 2022 2:46 pm; edited 1 time in total

----------

## arfe

 *mike155 wrote:*   

> Meine Erfahrung ist, dass Gentoo um so besser funktioniert, je näher man an den Default-Einstellungen bleibt.

 

512 MB RAM Swap sind definitiv zu wenig. Vor allem bei einem emerge -e world.

----------

## mike155

 *arfe wrote:*   

> Und Du hältst 512 MB Swap wirklich für Ausreichend wenn er bei solch großen Paketen swappen muss? Vor allem wenn mehrere große Portage Pakete kompiliert werden müssen?
> 
> Entweder schraubst Du deine Kerne zurück oder erhöhst Mal Deinen Swap ordentlich. Auch 32 GB RAM können bei sehr großen Paketen sehr schnell voll sein.

 

Mach mal langsam.

1) uhai hat 32GB RAM und er verwendet -j9. das ist mehr als ausreichend. Ich rechne mit 2GB RAM pro Job. 2GB mal 9 Job sind 18GB. Da sind 32 GB mehr als ausreichend - selbst wenn man noch ein tmpfs auf /var/tmp/portage legt.

2) Vor 10 Jahren habe ich Swap auf allen meinen Maschinen ausgeschaltet - und es noch nie vermisst. Heutzutage braucht man Swap nicht mehr unbedingt. Wenn RAM tatsächlich mal knapp sein sollte, ist es mir lieber, ein Programm beendet sich gleich mit einer "Out of Memory" Fehlermeldung, als wenn die Maschine vorher noch anfängt, minutenlang exzessiv zu swappen - und der OOM Killer dann zuschlägt.

----------

## arfe

 *mike155 wrote:*   

> 
> 
> 1) uhai hat 32GB RAM und er verwendet -j9. das ist mehr als ausreichend. Ich rechne mit 2GB RAM pro Job. 2GB mal 9 Job sind 18GB. Da sind 32 GB mehr als ausreichend - selbst wenn man noch ein tmpfs auf /var/tmp/portage legt.
> 
> 

 

```
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/basic_string.h:6495:25: error: expected ‘;’ before ‘}’ token

 6495 |     { __lhs.swap(__rhs); }

      |                         ^~

      |                         ; 
```

Wenn das Deine irrige Meinung ist. LOL   :Very Happy: 

Sein Swap war zu dem Zeitpunkt bereits voll.

----------

## mike155

@arfe: das ist kein out-of-memory Fehler!

Zunächst einmal würde man bei einem OOM-Fehler keine Fehlermeldung des Compilers sehen. Wenn der Compiler vom OOM-Killer abgeschossen wird, hat er keine Zeit mehr, etwas auszugeben.

Stattdessen würde man im Build Log ein Meldung sehen wie:

```
x86_64-pc-linux-gnu-g++: fatal error: Killed signal terminated program cc1plus
```

Man könnte dann auch Meldungen des OOM-Killers in dmesg und in den System Logs sehen. 

Wir haben aber keine "kill signal" Meldung. Außerdem haben wir eine Fehlermeldung des C-Compilers. Und 32GB sind mehr als genug für "-j9". Klingt alles nicht nach OOM Fehler.

----------

## arfe

 *mike155 wrote:*   

> 
> 
> Außerdem haben wir eine Fehlermeldung des C-Compilers.

 

Jetzt ist der C-Compiler der Schuldige? Wahrscheinlich sogar das Paket.  :Very Happy: 

Ich bin hier raus. Ist nicht mein System. Ich habe übrigens das Paket vorhin testweise kompiliert.

```
Sun Feb 13 15:59:48 2022 >>> net-libs/webkit-gtk-2.34.5

       merge time: 20 minutes and 23 seconds.
```

Seine Flags sehen nämlich moderat aus:

```
CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=native -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="-march=native -O2 -pipe"

FCFLAGS="-O2 -pipe"

FFLAGS="-O2 -pipe" 

```

----------

## Christian99

 *arfe wrote:*   

> 
> 
> Sein Swap war zu dem Zeitpunkt bereits voll.

 

Wie kommst du da drauf? ich kann das nicht erkennen.

Und ich muss mike155 zustimmen, ein OOM Fehler sieht anders aus.

Der tatsächliche Fehler ist aber ein bisschen seltsam

```
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/string:55,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/locale_classes.h:40,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/ios_base.h:41,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/ios:42,

                 from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/ostream:38,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/common/globals.h:12,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/objects/visitors.h:8,

                 from ./../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/v8/src/objects/visitors.cc:5,

                 from gen/v8/v8_base_without_compiler_jumbo_36.cc:5:

/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/basic_string.h: In function ‘void std::swap(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)’:

/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/bits/basic_string.h:6495:25: error: expected ‘;’ before ‘}’ token

 6495 |     { __lhs.swap(__rhs); }

      |                         ^~

      |                         ;

```

Laut compiler ist es ein Syntaxfehler, einfach nur ein fehlendes ;

Wenn ich selber Code schreibe kommt das ständig vor, aber bei etwas releasden ist das eher ungewöhnlich, und auch die Stelle auf die der Compiler zeigt sieht eigentlich richtig aus, sie enthält ein ; an der richtigen Stelle, da müsste man mal ein bisschen den kontext anschauen...

@uhai

```

PORTAGE_TMPDIR="/home/uhai/Fotos"

```

das ist tatsächlich ein bisschen ungewöhnlich. Grundsätzlich sollte es erst mal kein Problem sein, das so zu machen, aber es "passt" da eigentlich nicht hin. Meiner erfahrung nach kommt man mit solchen ungewöhnlichen Sachen dann leicht durcheinander. Z.b. folgt man irgend einer Anleitung, und denkt grad mal nicht dran, das bei einem selbst da was anders ist und man eigentlich die Anleitung bei sich selbst anpassen müsste, oder so ähnlich.

Wie gesagt, grundsätzlich sollte es erst mal kein Problem sein, aber das muss dann jeder selber wissen. Ich würde jedoch davon abraten.

Du hast gemeint, du hast das gemacht, weil ein Paket mehr Platz gebraucht hat, da würde ich dann erst mal schauen, wieso du da so wenig platz hast. Wie sieht denn dein Festplatten/partitionslayout aus?

----------

## arfe

 *Christian99 wrote:*   

> 
> 
> Laut compiler ist es ein Syntaxfehler, einfach nur ein fehlendes ;
> 
> Wenn ich selber Code schreibe kommt das ständig vor, aber bei etwas releasden ist das eher ungewöhnlich, und auch die Stelle auf die der Compiler zeigt sieht eigentlich richtig aus, sie enthält ein ; an der richtigen Stelle, da müsste man mal ein bisschen den kontext anschauen...
> ...

 

Welchen Kontext? Da gibt es keinen Fehler. Es lässt sich problemlos kompilieren. Aber ich bin hier raus. Ich weiß, dass ich nicht falsch liege. Ist nicht mein System!

----------

## firefly

 *arfe wrote:*   

>  
> 
> ```
> Sun Feb 13 15:59:48 2022 >>> net-libs/webkit-gtk-2.34.5
> 
> ...

 

Wer redet hier von webkit-gtk?

uhai hat probleme mit dem paket dev-qt/qtwebengine-5.15.2_p20211216. Also bitte erst mal genauer lesen bevor man antwortet...

Und wenn ein system mal länger läuft ist es nicht unwahrscheinlich dass swap mal ein paar hundert MB enthält. Selbst bei 32GB RAM.

Aber der fehler hat nichts mit out of memory zu tun wie dir schon Christian99 und mike155. Denn die fehlermeldung im Log ist da hundert prozentig eine andere (und die hat mike155 auch schon genannt)

Es ist ein reiner compiler fehler. Wobei dir Frage ist was ist hier kaputt/inkompatibel.

Eventuell ist die gcc-11 installation defekt oder dev-qt/qtwebengine in der version 5.15.2_p20211216 ist nicht kompatibel mit gcc 11

Aber das ist alles pure spekulation.

Zum test mach ich gerade ein update von dev-qt/qtwebengine-5.15.2_p20211216. Nur halt mit gcc 10.3.0-r2

----------

## firefly

 *Christian99 wrote:*   

> 
> 
> Du hast gemeint, du hast das gemacht, weil ein Paket mehr Platz gebraucht hat, da würde ich dann erst mal schauen, wieso du da so wenig platz hast. Wie sieht denn dein Festplatten/partitionslayout aus?

 

qtwebengine braucht recht viel plattenplatz beim bauen. Besonders wenn man viele parallele jobs laufen lässt (-j<X> in MAKEOPTS).

Ich hatte vor einem jahr noch /var/tmp/portage in einem tmpfs mit 10GB größe. Das hatte nicht ausgereicht. Aktuell nutze ich 16GB (statt tmpfs ist es ein zram) Und das reichte bisher bis dev-qt/qtwebengine-5.15.2_p20211019.

----------

## firefly

 *firefly wrote:*   

> Zum test mach ich gerade ein update von dev-qt/qtwebengine-5.15.2_p20211216. Nur halt mit gcc 10.3.0-r2

 

Der test ist fertig. Das übersetzen hat bei mir geklappt.

@uhai welchen useflags sind bei dir für qtwebengine aktiv?

Bei mir sind es folgende:

 *Quote:*   

> dev-qt/qtwebengine-5.15.2_p20211216:5/5.15::gentoo  USE="alsa pulseaudio system-ffmpeg system-icu widgets -bindist -debug -designer -geolocation -jumbo-build -kerberos -test"

 

----------

## arfe

 *firefly wrote:*   

>  *arfe wrote:*    
> 
> ```
> Sun Feb 13 15:59:48 2022 >>> net-libs/webkit-gtk-2.34.5
> 
> ...

 

Das ist mir total egal. Von @uhai kommt viel wirres Zeug und springt von einem Thema zu einem anderen. Ist nicht mein System. Und ich bleibe auch bei meiner vorherigen Aussage.

Zu dem o.g. Aussage von Dir hiermit vernünftig  gelöst ist: https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs

Stichwort: notmpfs in dem Wiki-Tutorial.

----------

## uhai

OK,

die Portage_TEMPDIR ist schon lange auf mein Foto-Verzeichnis gesetzt (> 5 Jahre?) und war nie ein Problem. Ich habe sie eben mal auf Standard gesetzt, bricht aber genauso ab.

Aktuell kann ich mit emerge --resume --skipfirst auch nicht weitermachen, weil webkit-gtk ebenfalls nicht durchläuft. Ich dachte, dass könnte evtl. einen Hinweis auf die Ursache geben, deshalb habe ich das build.log oben ebenfalls verlinkt....

Der Swap-Bereich ist so klein, weil ich davon ausging, dass ich nicht auslagern muss mit 32 GB RAM. Das RAM brauche ich für die Bildbearbeitung. Bisher habe ich auch noch nicht beobachtet, dass mein Speicher voll ausgelastet wäre... Habe ich das Swap-Prinzip falsch verstanden? @arfe - danke für den Link, schau ich mir in Ruhe an.

Bevor ich hier weiter teste - wie beseitige ich die Rückstände der abgebrochenen Versuche?

Die USE-FLAGS sind so gesetzt:

```
emerge -p dev-qt/qtwebengine

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] dev-qt/qtwebengine-5.15.2_p20211216  USE="alsa jumbo-build system-ffmpeg system-icu widgets -bindist -debug -designer -geolocation -kerberos -pulseaudio -test"
```

Das qtwebengine war auch schon installiert, hat das letzte mal beim Update aber auch herumgezickt. Ich weiß nur nicht mehr, was ich damals gemacht habe....

uhai

----------

## firefly

deaktiviere jumbo-build gut möglich dass das probleme macht

----------

## Christian99

hm, ich bin mir nicht wirklich sicher was da bei dir los ist, aber die beiden Fehler würde ich unter "seltsames Compilerverhaltern" kategorisieren.

Dann würde ich mal damit anfangen, gcc neu zu isntallieren. vielleicht ist der ja nur irgendwie kaputt gegangen.

Falls das nicht hilft, kannst du danach mal eine andere gcc version probieren, entweder eine ~ 11.2, oder die vorige stable 10.3.

Aber ist nur geraten...

----------

## demiurg

Noch zum Thema XMP für den Ram.

Die Einstellung ist, wie richtig bemerkt, im BIOS zu finden. Bei mir sind 4 Riegel verbaut, die ohne aktiviertem XMP Profil "nur" mit 2133 Mhz laufen (und 1,2V) mit aktiviertem XMP ist die Taktfrequenz auf 3000 Mhz programmiert (und 1,35V). Mit aktiviertem XMP bricht der Compilerlauf mit gleicher "Fehlermeldung" ninja: build stopped: subcommand failed, aber an anderer Stelle ab. Ohne aktiviertes XMP Profil läuft das Compilieren durch. Das Verhalten tritt auch nur bei qtwebengine auf. Andere Pakete haben bei 3000Mhz für den Ram kein Probleme.

Gruß

demiurg

----------

## arfe

 *demiurg wrote:*   

> Das Verhalten tritt auch nur bei qtwebengine auf. Andere Pakete haben bei 3000Mhz für den Ram kein Probleme.

 

Nicht die Pakete haben ein Problem mit Deinem RAM, sondern Dein RAM hat ein Problem mit der Taktung. XMP sollte man nur so hochdrehen wie es auch stabil mit dem RAM läuft.

----------

## uhai

@firefly:

USE jumbo-build habe ich eben deaktiviert, teste ich als nächstes

@christian99:

alles anderen Pakete laufen sauber durch, müssten die bei einem beschädigten gcc  nicht auch Probleme haben?

@demiurg:

Danke für Deine Erklärung, schaue ich mir demnächst mal an. Momentan brauche ich den Rechner und kann nicht unterbrechen. 

@arfe:

Sorry, wenn ich wirres Zeug poste, ich lerne nur aus Fehlern und bin eigentlich nur Anwender. Deinem Hinweis (Danke dafür) gehe ich noch nach, momentan komme ich neben Job & Familie zu nichts...

uhai

----------

## uhai

Also ohne jumbo-build geht es auch nicht:

[code]In file included from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/public/browser/web_contents.h:29,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/public/browser/download_manager_delegate.h:21,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/browser/devtools/protocol/devtools_download_manager_delegate.h:19,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/browser/devtools/protocol/page_handler.h:24,

                 from ../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/browser/devtools/protocol/page_handler.cc:5:

../../../../qtwebengine-5.15.2_p20211216/src/3rdparty/chromium/content/public/browser/navigation_controller.h:272:36: internal compiler error: Segmentation fault

  272 |   virtual ~NavigationController() {}

      |                                    ^

0x172d66f internal_error(char const*, ...)

        ???:0

0x883d6b ggc_set_mark(void const*)

        ???:0

0xa86fb3 gt_ggc_mx_control_flow_graph(void*)

        ???:0

0xa89536 gt_ggc_mx_function(void*)

        ???:0

0x7ec9bd gt_ggc_mx_lang_tree_node(void*)

        ???:0

0xa824c8 gt_ggc_mx_vec_tree_va_gc_(void*)

        ???:0

0x7ed42f gt_ggc_mx_lang_type(void*)

        ???:0

0x7ec74e gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ebdd6 gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7eb613 gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec69d gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec68f gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ebdd6 gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec75f gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec705 gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec8f0 gt_ggc_mx_lang_tree_node(void*)

        ???:0

0xa824c8 gt_ggc_mx_vec_tree_va_gc_(void*)

        ???:0

0x7ed42f gt_ggc_mx_lang_type(void*)

        ???:0

0x7ec74e gt_ggc_mx_lang_tree_node(void*)

        ???:0

0x7ec473 gt_ggc_mx_lang_tree_node(void*)

        ???:0

[code]

build.log: http://0x0.st/o8fZ.log[/code]

----------

## Christian99

 *uhai wrote:*   

> 
> 
> @christian99:
> 
> alles anderen Pakete laufen sauber durch, müssten die bei einem beschädigten gcc  nicht auch Probleme haben?

 

Vielleicht, vielleicht auch nicht. Wenn es irgendwas ist, das selten vorkommt etc.. ist es evtl nur bei wenigen Paketen dass das problem auftritt.

Aber, hauptsächlich ist es tatsächlich nur ein Versuch, weil ich auch nix besseres mehr weiß.

----------

## Josef.95

Ja, ich denke die Idee es mal mit einem neueren gcc:11 Snapshot zu versuchen ist gut.

 *uhai wrote:*   

> alles anderen Pakete laufen sauber durch

  Hm nee, dein webkit-gtk steigt ja auch mit einem

"internal compiler error: Segmentation fault" error aus :-/

Ich würde es mal mit dem aktuellen =sys-devel/gcc-11.2.1_p20220115 versuchen

( das ist übrigens auch der aktuelle neue stable Kandidat, siehe Bug 833357 )

```
echo "=sys-devel/gcc-11.2.1_p20220115" >> /etc/portage/package.accept_keywords

emerge -av1 sys-devel/gcc:11
```

 Und dann mal mit dem neuen gcc testen :)

----------

## uhai

Danke Josef95, das mache ich gleich.

webkit-gtk lief gestern plötzlich durch.... Also aktuell ist es nur qtwebengine wo es noch klemmt.

webkit--gtk lief mit USE=-jumbo-build, vermutlich war es das...

Ram-Taktung ist 1600 MHz, da ist nichts verstellt.

uhai

<edit>wieder abgebrochen, gcc-Tausch hat auch nicht geholfen. Hier ist das build.log:

http://0x0.st/o8YB.log </edit>

----------

## arfe

 *uhai wrote:*   

> 
> 
> <edit>wieder abgebrochen, gcc-Tausch hat auch nicht geholfen. Hier ist das build.log:
> 
> http://0x0.st/o8YB.log </edit>

 

Segmentation fault:

Ich würde Mal fast behaupten, dass Dein RAM kaputt ist. Zumindest einer von den Riegeln.

----------

## uhai

ich habe mir mal memtest86+ installiert und dmesg zeigt mir nun diesen Fehler:

```
[  912.156659] process '/memtest86plus/memtest' started with executable stack

[  912.156719] traps: memtest[5175] general protection fault ip:100001 sp:ffd12930 error:0 in memtest[100000+2c000]

[ 8248.463804] traps: node[248909] trap invalid opcode ip:560574aa38e9 sp:7fffde4b0408 error:0 in node[560574a89000+d56000]

```

Ich nehme mal an, damit hat arfe mit seiner Einschätzung, das ein Teil meines Speichers defekt ist Recht....

Macht das hier beschriebene Vorgehen mit memmap Sinn? Dann könnte ich zumindest vorerst mal weiter arbeiten....

uhai

----------

## firefly

Nein. AFAIK kann memtest86+ nicht in linux laufen sondern man muss es separat starten via bootloader.

z.b. für Grub hab ich das hier gefunden:

https://askubuntu.com/questions/126160/how-can-i-add-the-memtest86-options-back-to-the-grub-menu

----------

## Josef.95

Jo, das Paket sys-apps/memtest86+ mit USE=boot (ist default enabled) gebaut installiert das gebaute binary nach /boot

und bringt für GRUB sogar schon einen vorbereiteten bootloader-Eintrag mit.

```
pkg_postinst() {

        if use boot; then

                mount-boot_pkg_postinst

                elog "memtest86+ has been installed in ${BOOTDIR}/"

                elog "You may wish to update your bootloader configs:"

                elog " - For grub2 just re-run grub-mkconfig -o /boot/grub/grub.cfg, since a"

                elog "   config generator has been installed at /etc/grub.d/39_${PN}"

                elog " - For lilo, add the following to /etc/lilo.conf and re-run lilo:"

                elog "    > image  = ${BOOTDIR}/memtest.bin"

                elog "    > label  = ${PN}"

                elog ""

                elog "Note: For older configs, you might have to change from 'memtest' to 'memtest.bin'."

        fi

        if use boot && [ -e /sys/firmware/efi ]; then

                ewarn "WARNING: You appear to be booted in EFI mode but ${PN} is a BIOS-only tool."

        fi

}
```

----------

## uhai

Ich habe sys-apps/memtest86-4.3.7-r2::gentoo installiert und im grub-Menü taucht die Option auf. Allerdings wird nach Auswahl des Eintrags der Bildschirm dunkel.... und nichts passiert.

/boot war zur Installation gemountet. 

```
 ls /boot/memtest86

memtest  memtest.bin
```

Was kann da schief gelaufen sein?

uhai

----------

## mike155

Als ich vor einem halben Jahr meinen neuen Ryzen Rechner in Betrieb genommen habe, wollte ich ihn natürlich zuerst mit Memtest testen. Die mit den Gentoo ebuilds gebauten Versionen haben nicht funktioniert. 

Wenn ich mich richtig erinnere, hat die mit SystemRescue mitgelieferte Version funktioniert.

Letztendlich habe ich aber das USB Image von http://www.memtest86.com/ heruntergeladen. Dieses habe ich auf einen USB Stick kopiert und davon gebootet. Das hat gut funktioniert.

Verwendest Du UEFI boot? Dann kannst Du die neueste Version 9.4. verwenden. Falls Du noch BIOS boot verwendest, brauchst Du die ältere Version 5.

----------

## uhai

so, danke Mike155 mit memtest86-bin hat es geklappt. Das Ergebnis ist allerdings weniger schön:

lowest error adress ist bei 18120 MB

highest error adress ist bei 30160 MB

Das heißt aber nicht, das alles zwischen diesen Werten fehlerhaft ist, oder? Das wäre ja mein halber Arbeitsspeicher.... Um die fehlerhaften Bereiche zu sperren müsste ich doch genauere Angaben haben.... Kann ich aus memtest86 ein logfile bekommen?

uhai

----------

## mike155

memtest86-bin schreibt ein Logfile in das Verzeichnis, in dem auch das Binary liegt.

Wenn Du defektes Memory hast: überprüfe zuerst im BIOS-Setup, dass für Memory-Zugriffe auch wirklich die Standard-Einstellungen verwendet werden (und keine Overclocking-Einstellungen). 

Dann würde ich versuchen herauszufinden, welcher Riegel defekt ist. Dazu würde ich die Riegel so lange tauschen und immer wieder memtest ausführen, bis ich weiß, welches der defekte Riegel ist.

Den defekten Riegel würde ich ersetzen.

Es gibt auch Lösungen, bei denen man den defekten Riegel im System lässt. Entweder teilt man dem Kernel mit, welche Speicherbereiche defekt sind (Kernel-Parameter memmap) - oder man lässt das den Kernel selbst ermitteln (Kernel-Option CONFIG_MEMTEST, Kernel-Parameter memtest). Der Kernel wird dann entsprechende Speicherbereiche nicht verwenden. Das wird auch in diesem Thread beschrieben.

Ich würde das aber nicht empfehlen! Wenn ein Speicherriegel defekt ist, sollte er ausgetauscht werden. Das ist wesentlich sicherer! Problematisch sind Speicherzellen, die nicht vollständig defekt sind - sondern nur gelegentlich falsche Werte zurückgeben. Diese findet man mit einem kurzen Memtest nicht oder nur manchmal.

Linus Torvalds hat hierzu übrigens eine ganz klare Meinung: man sollte kein RAM ohne ECC verwenden. Er schimpft deswegen auch gelegentlich auf Intel, die ECC hauptsächlich ihren Server-Prozessoren vorenthalten: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/55019-fehlende-ecc-unterstuetzung-linus-torvalds-schimpft-ueber-intel.html.

----------

## ManfredB

Ich bin gerade dabei, dev-qt/qtwebengine testweise auf gentoo-stable (systemd) zu installieren.

qtwebengine ist in der monster.conf eingetragen, MAKEOPTS ist per # deaktiviert,

/var/tmp/portage ist in tmpfs.

Die Freiheit ist für qtwebengine eingeschränkt auf -j6.

Ich beobachte dabei, daß der RAMSpeicher (32 GB) nur zur Hälfte genutzt wird.

43 Minuten läuft es jetzt.

Ich bin sehr gespannt, ob das problemlos so zu Ende geht.

Gruß

Manfred

P.S. Erfolg: nach 1 Stunde und 14 Minuten war qtwebgine installiert.

Ehrlich gesagt: genau aus diesem Grund, daß der Prozess so lange dauert,

habe ich bisher qtwebengine in der make.conf unter USE mit - versehen.

Allerdings habe ich nur Teile von kde-apps installiert, so daß qtwebengine nicht dran kam.

Aber daß es unter diesen Einstellungen funktioniert hat, erfreut mich nun doch.

Allerdings hätte ich die Zeit sicher auch etwas kürzen können, wenn ich statt -j6 einfach -j8 genommen hätte.

Und nun bin ich nach Jahren wieder dabei kde-apps/kde-apps-meta zu installieren: 198 Pakete.

Nebenbei ist auch ein binpkg entstanden, das ermöglicht mir, auch andere gentoo-Installation damit auszustatten

in deutlich schnellerem Tempo.

----------

## ManfredB

Heute habe ich in gentoo-unstable (systemd) auch qtwebengine zugelassen.

In der Datei /etc/portage/env/monster.conf steht:

MAKEOPTS="-j8"

Dadurch hat es hier nur 56 Minuten gedauert.

Gruß

Manfred

----------

## arfe

 *ManfredB wrote:*   

> Heute habe ich in gentoo-unstable (systemd) auch qtwebengine zugelassen.
> 
> In der Datei /etc/portage/env/monster.conf steht:
> 
> MAKEOPTS="-j8"
> ...

 

Hast Du denn überhaupt verstanden um was es hier geht? Deine Eingaben sind wenig hilfreich für @uhai.

@uhai hat mit sehr hoher Wahrscheinlichkeit einen kaputten RAM-Riegel. Da hilft es überhaupt nicht, dass bei

Dir der Build funktioniert.

Zu dem ohne Angabe Deiner USE-Flags Du damit niemanden helfen würdest wie Du deinen Build gemacht hast.

----------

## ManfredB

Sorry, wenn ich hier außerhalb meinen Versuch gestartet habe.

Ich habe zwar den Thread von Anfang an verfolgt. Dennoch habe ich bei meinem Test wohl das eine oder andere nicht mehr in Erinnerung gehabt.

Daher bitte ich um Entschuldigung, daß ich mich hier eingemischt habe.

Es ging dabei nicht um mich und meinen Erfolg, sondern ich wollte testen,

ob bei mir dieses Problem mit qtwebengine auch auftaucht.

Schade, daß ich da etwas mißverstanden habe.

Voller Scham wende ich mich hier nun heraus, wünsche aber dem Verfasser des Threads Erfolg.

Liebe Grüße

Manfred

----------

## uhai

Ich habe meinen Kernel um memtest erweitert, jetzt ging qtwebenginge durch.

Aber das ist nur die kurzfristige Lösung. anhand des Memtest-Protokolls werde ich den defekten Baustein ersetzen....

Vielen Dank für Eure Unterstützung, ich habe wieder viel gelernt von Euch.

uhai

----------

## arfe

 *uhai wrote:*   

> Aber das ist nur die kurzfristige Lösung. anhand des Memtest-Protokolls werde ich den defekten Baustein ersetzen....
> 
> Vielen Dank für Eure Unterstützung, ich habe wieder viel gelernt von Euch.
> 
> 

 

Dann lag ich mit meiner Vermutung richtig.

----------

## musv

Auch wenn der RAM-Baustein der eigentliche Fehler war, ist qtwebengine generell nicht unproblematisch.

 *ManfredB wrote:*   

> Heute habe ich in gentoo-unstable (systemd) auch qtwebengine zugelassen.
> 
> In der Datei /etc/portage/env/monster.conf steht:
> 
> MAKEOPTS="-j8"
> ...

 

Richtiger Ansatz, falsche Interpretation.

tldr:

Anzahl Jobs < RAM / 2

Genauere Erklärung:

Ich hab MAKEOPT="-j13" stehen (Hexacore -> 12 logische Cores + 24GB Ram). Und schlägt das Build ebenfalls fehl. Mit "-j8" klappt's. Ich find jetzt die Quelle nicht mehr. Allerdings krallt sich qtwebengine (die Chrome-Komponenten darin) pro Build-Job 2 GB RAM. Stellt man also zuviele Jobs ein, mündet das in einen SWAP-Stresstest. 

Für Jumbo-Builds brauchst du wohl mind. 64GB, damit das durchläuft. 

Cool find ich ja die Warnung am Ende des Ebuilds:

 *Quote:*   

> pkg_preinst() {
> 
>         elog "This version of Qt WebEngine is based on Chromium version 87.0.4280, with"
> 
>         elog "additional security fixes from newer versions. Extensive as it is, the"
> ...

 

----------

