site  contact  subhomenews

OE gcc target default commandline options

October 15, 2020 — BarryK

I uploaded Easy Dunfell 0.91 yesterday:

https://bkhome.org/news/202010/easyos-dunfell-series-091-alpha-release.html

Which was a disaster, as most people couldn't get it to boot. I had feedback from Rodney, Feodor and David, and on the forum, banned and average1. I received an email from Alfons confirming that the USB-stick booted on a PC with Intel i7 CPU, not earlier CPUs.

The problem is a bug in OE. I set the target as an Intel Core2 CPU, which is one of the earliest x86 64bit CPUs. That's fine, all of the applications were compiled for a Core2 CPU. However, after building EasyOS, and compiling the Linux kernel, SeaMonkey and Libreoffice in a running EasyOS, then building Easy 0.91 with those, that's when disaster struck.

The gcc compiler in a running EasyOS does not default to Core2, it compiles using extra instructions that are in my i3 CPU but not in earlier CPUs.

On the Internet I found a simple way to discover the default options that gcc uses, and did this in Easy 0.91:

# echo "" | gcc -v -E - 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-poky-linux/9.3.0/cc1 -E -quiet -v - -march=core2 -mmmx -mno-3dnow \
-msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul \
-mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-pconfig \
-mno-wbnoinvd -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle \
-mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave \
-mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 \
-mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma \
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku \
-mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq \
-mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite -mtune=generic

 Wow! Complicated, but I would have thought it would be OK with that "-march=core2". Obviously not though.

OE's most generic x86_64 CPU setting is Core2, but back when I ported the Pyro release of OE, I modified it for a Nocona CPU, which is the earliest 64-bit CPU. I attempted to port those Nocona changes into my Dunfell OE derivative, and did a complete recompile today. It did seem to have compiled everything for a Nocona CPU, but now I have used those packages and built Easy 0.92, and applied the same test:

# echo "" | gcc -v -E - 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-poky-linux/9.3.0/cc1 -E -quiet -v - -march=skylake -mmmx -mno-3dnow -msse \
-msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm \
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx \
-mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw \
-madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf \
-mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl \
-mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx \
-mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes \
-mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote \
-mno-ptwrite -mtune=generic

Oh dear, "-march=skylake" is not what I want!

So, I booted up Easy Pyro 1.3:

# echo "" | gcc -v -E - 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-oe-linux/6.3.0/cc1 -E -quiet -v - -mtune=generic -march=x86-64

Nice and simple!

This is going to take me a bit longer to fix. I think what I want is "-march=nocona -mtune=nocona" and I have to study OE and find out how it has gone wrong, and how all that other stuff has got in.

Changing the subject...

Gtk3 scrollbar

If you have used a GTK-based app, such as SeaMonkey, you might have noticed how annoying the scrollbars have become. In gtk2 if you click above or below the slider, the window will scroll up or down by one window of text. Gtk3 on the other hand, there will be a jump way up or down in the text file, which is hopeless if you want to scroll through the text a window-height at a time.

Some gtk3 themes do restore the gtk2 behaviour, but it is not the default. However, I after a bit of online searching, I found the fix. Add this line under "[Settings]" in /root/.config/gtk-3.0/settings.ini:

gtk-primary-button-warps-slider = false

I have put this into woofQ. 

Tags: oe