[lfs-dev] Oddities while testing.

Alain Toussaint atoussaint1976 at gmail.com
Sat Jun 3 16:56:39 PDT 2017


> First, it is really good to know of people who build svn regularly.

My futur plans is to configure jenkins or another kind of buildbot to
do it unattended on a spare computer.

>  And glibc built without
> problems, but perhaps that is because I pass CFLAGS and CXXFLAGS of
> "-O2".

I do use CFLAGS and CXXFLAGS for the usb that are generic enough for
x86_64. This one build is using -Os and -mtune=generic because I am
building for any x86_64 computers (at work and at home) with one usb
key targeting UEFI bioses (using the refind
http://www.rodsbooks.com/refind/ bootloader), the other one targeting
older bioses but essentially, I'm using ramdrives for the root image,
thus the -Os build.

Other flags used are the minimum sse flags featured by the oldest
x86_64 chips ever built (amd athlon and intel pentium 4 64 bits) which
is sse and sse2. From the documentation given by gcc (source:
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html#x86-Options):

"For the x86-32 compiler, you must use -march=cpu-type, -msse or
-msse2 switches to enable SSE extensions and make this option
effective. For the x86-64 compiler, these extensions are enabled by
default."

"The resulting code should be considerably faster in the majority of
cases and avoid the numerical instability problems of 387 code, but
may break some existing code that expects temporaries to be 80 bits"

Of the many years that I used gentoo (since year 2004) before and
since last year, LFS, this has never been the case and gcc always
default to the 387 for floating point instructions and data.

To figure out the options used by default for the compiler:

gcc -c -Q --march=native --target=help

or in my case: gcc -c -Q --march=generic --target=help

the set of CFLAGS:

"-Os -pipe -m128bit-long-double -m80387 -m64 -malign-data=cacheline
-malign-double -mtune=generic -mfancy-math-387 -mfentry
-mfp-ret-in-387 -mfpmath=sse -mglibc -mhard-float -mieee-fp -msse
-msse2 -mincoming-stack-boundary=4 -mpreferred-stack-boundary=4
-mno-sse4 -mred-zone -msseregparm"

Some of these are indeed redundant and I need to learn how to read and
dissect gcc source code for my desired effect (pad to 16 bytes
alignments, use sse units for math and zerofill 80 bit float to 128
bit and finally, use all registers available).

> I don't build systemd, but I _had_ been using gold for most of my
> builds in the last year (newer, shinier, claimed to be faster).

I never intended to use gold either but the configure script for
systemd-233 look for it and build with it. In binutils 2.25, that
worked fine but in 2.28, there was a regression in the code and a
number of projects had build failures which was fixed in binutils svn.
I'll be attempting a build later on to document it but at the moment,
I stopped at the glibc build in chapter 6 which has more failures
compared to my usual build targeting this computer (usually, I have
only 2 tests that fail with a ton more CFLAGS but for this build, I
have 352 FAIL in the testlogs):

A short sample (log file available on request):

FAIL: conform/ISO/assert.h/linknamespace
FAIL: conform/ISO/locale.h/linknamespace
FAIL: conform/ISO/math.h/linknamespace
FAIL: conform/ISO/signal.h/linknamespace
FAIL: conform/ISO/stdio.h/linknamespace
FAIL: conform/ISO/stdlib.h/linknamespace
FAIL: conform/ISO/string.h/linknamespace

I haven't installed the resulting glibc build but will rebuild again
without any CFLAGS.

All the rest of the software build and test usually fine with my set of CFLAGS.

Alain


More information about the lfs-dev mailing list