| View previous topic :: View next topic |
| Author |
Message |
nkichukov
n00b
Joined: 16 Oct 2012
Posts: 14
Location: Amstelveen, Netherlands
|
 Posted: Tue Oct 08, 2019 10:25 pm Post subject: |
 |
|
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: | 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: | | ...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 |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54250
Location: 56N 3W
|
| Posted: Wed Oct 09, 2019 5:12 pm Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
nkichukov
n00b
Joined: 16 Oct 2012
Posts: 14
Location: Amstelveen, Netherlands
|
| Posted: Sat Oct 12, 2019 7:04 pm Post subject: |
|
|
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: | * 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: | # 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: | 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: |
* 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: | 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 |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54250
Location: 56N 3W
|
| Posted: Sat Oct 12, 2019 7:41 pm Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
