Chromium ebuild for arm64?

[nkichukov]

I've tried from rpi4 4gb, but it fails, which is expected, as I just monitored the 'ld' call from the qemu-aarch64 chroot which hit 14GB RSS... and then failed(without any OOM errors). I am compiling on amd64, under qemu-aarch64 with enough memory. I also make use of cross-compiler(distcc), to speed it up(-j4 -l1 as the most restricted set of switches but it still fails).

when I tried to manually execute one of the failed commands just before the linker, from 'out/Release' folder, ie:

Code: Select all

aarch64-unknown-linux-gnu-g++ -Wl,--version-script=../../build/linux/chrome.map -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -licui18n -licuuc -licudata -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lxml2 -lfontconfig -ldbus-1 -lXss -lresolv -lgio-2.0 -lz -lpng16 -lwebpdemux -lwebpmux -lwebp -lfreetype -ljpeg -lexpat -lharfbuzz-subset -lharfbuzz -ldrm -lXrandr -lre2 -lsnappy -lpci -lasound -lavcodec -lavformat -lavutil -lopus -latk-1.0 -latk-bridge-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lminizip -latspi -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt -lm -lopenh264

I got:

Code: Select all

...libaudio_network_adaptor.a: error adding symbols: malformed archive

use flags:
www-client/chromium -hangouts pulseaudio -suid jumbo-build

USE contains -O3,perhaps worth trying with -O2.

Cheers,
-N

[NeddySeagoon]

nkichukov,

Beware -O3. Its not safe globally.

It enables expensive optimisations which also make the code bigger is an attempt to make the code faster.
Making the code bigger to make it faster depends on the working set still fitting into the CPU cache.
When that does not happen the bigger code generates a lot of cache misses which are satisfied by the much slower accesses to main RAM.
You end up with cache thrashing and much slower execution than you would have with -O2 or -Os

There are other architecture dependant down sides to -O3 too.
Like on AMD/Intel systems it does not always return the FPU results you expect.

Leave -O3 for developers to set in their build systems on the functions they test it with.

[nkichukov]

Back to the chromium compile task, I managed to compile it on the raspberrypi 4 itself in the end, with the help of a distributed compiler to save on time... Here is the result for chromium-77.0.3865.90:

Code: Select all

 * Final size of build directory: 5805297 KiB (  5.5 GiB)
 * Final size of installed tree:   458178 KiB (447.4 MiB)
real    358m59.283s
user    140m15.309s
sys     32m32.286s

using:

Code: Select all

# cat /etc/portage/env/{notmpfs,makeopts-l1}.conf 
PORTAGE_TMPDIR="/var/tmp/notmpfs"
MAKEOPTS="-j6 -l1"

and had to append the crypto extension to the C/CPP FLAGS:

Code: Select all

COMMON_FLAGS="-O3 -pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc+crypto -mtune=cortex-a72"

as without it it was failing to compile.


But what brought me here, in this forum thread in the first place? I used the base template for aarch64 I downloaded from Gentoo, which had the make.conf file setup to contain a new to me variable, which I ignored in the hurry:
COMMON_FLAGS.

What I overlooked was, I only set my CFLAGS variable and then comment out the COMMON_FLAGS, believing this is the CFLAGS and leaving all the other compilers' parameters being sourced from COMMON_FLAGS(which was an empty string).

What this caused was, code without any optimizations to be generated, which was causing my raspberrypi and also the qemu-aarch64 chroot to run out of memory during linking no matter what.

Lesson learned!

What helped me to identify this error was another gentoo package which was failing to install... webkit-gtk. The source code has a check whether the compiler runs with optimizations and if it does not it errors out and fails to compile with:
"WebKit will be slow. Set -DRELEASE_WITHOUT_OPTIMIZATIONS if this is intended"

Well done webkit-gtk and thank you.


Regarding the topic with -O3 compiler flag and whether to use it or not, I run arm, aarch64 and amd64 machines compiled with -O3 and I have not seen any performance drawbacks. Again, most of the critical packages would overwrite it to a "sane" default, like in the case of chromium:

Code: Select all

 * strip-flags: CFLAGS: changed '-O3 -pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72' to '-pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72 -O2'
 * strip-flags: CXXFLAGS: changed '-O3 -pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72' to '-pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72 -O2'
 * strip-flags: FFLAGS: changed '-O3 -pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72' to '-pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72 -O2'
 * strip-flags: FCFLAGS: changed '-O3 -pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72' to '-pipe -mlittle-endian -mabi=lp64 -march=armv8-a+crc -mtune=cortex-a72 -O2'

Again, I have not done any real comparison on benefits/drawbacks of having it enabled either. The only issues I had was with silent library crashes, thus I have those in the -O2 list:

Code: Select all

media-libs/alsa-lib gcc-O2.conf
net-libs/libnice gcc-O2.conf
media-libs/gstreamer gcc-O2.conf
dev-libs/glib gcc-O2.conf
app-emulation/virt-viewer gcc-O2.conf

NeddySeagoon, your response about -O3 does make sense to some extent so I will put some more research into it when time allows. Thank you.

Cheers,
-Nikolay

[NeddySeagoon]

nkichukov,

On amd64 and x86 -O3 will introduce you to the Intel 'Floating Point Excess Precision' bug.
It was introduced in the 8087, which was the FPU for the 8086 and everyone is used to it, so it can't be fixed now.

In summary the FPU works to 80 bits internally but a memory write only saves 64 bits.
With -O3, the SSE instruction set does a lot of the FPU instructions. It has its own registers and they are only 64 bits so you get different answers due to rounding.
Its actually -funsafe-math that does this, which -O3 enables.

Now you can go down the rabbit hole of what the various -O levels do to your FPU results and why.
Its an Intel/AMD issue only. Intel were first with a hardware FPU in the 8087 and everyone else learned from their mistake.