Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71777 - [gcc] GCC is built with suboptimal CFLAGS / LDFLAGS

Attached to Project: Arch Linux
Opened by Toolybird (Toolybird) - Monday, 09 August 2021, 05:57 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 31 August 2021, 15:30 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No


Most of the installed binaries in an Arch GCC build are not compiled with preferred CFLAGS / LDFLAGS (from makepkg.conf). The reason is due to a combination of factors:

1. Arch uses the default Makefile target which performs a 3-stage bootstrap (3rd stage is what gets installed)
2. Arch doesn't employ the documented[1] BOOT_CFLAGS var, or the badly documented BOOT_LDFLAGS var.

Essentially, to pass preferred FLAGS passed down into the 2nd and 3rd stages of the bootstrap, one has to utilise BOOT_*FLAGS vars. This is what other distros do e.g: Fedora[2] and Debian[3]. (Sidenote: those links demonstrate why most of us appreciate the utter simplicity of PKGBUILDs :)

Now, just to complicate matters there are also *FLAGS_FOR_TARGET vars which affect how the target libraries get built.

In oversimplified terms the payload of a GCC build comprises of:

- compilers (gcc, g++, cpp, cc1, etc.)
- target libs (libgcc, libstdc++, and friends)

In the current Arch GCC build, CFLAGS are carried through to CFLAGS_FOR_TARGET. LDFLAGS are mostly lost (I say mostly because they do get used in certain less important parts of the build). BOOT_*FLAGS just get the defaults.

The upshot of all this means the status quo is as follows (using current distro FLAGS from devtools):


target libs:
CFLAGS_FOR_TARGET="-g -march=x86-64 -mtune=generic -O2 -fno-plt"
(-g is added by GCC configury, -pipe is filtered out in PKGBUILD)

This came to light while looking into ways to improve the bootstrap of the full Arch toolchain (see FS#70954). Interestingly, if you build GCC with `--disable-bootstrap', the compilers *are* built with preferred CFLAGS / LDFLAGS but the target libs are the same. Also, I will note here it is possible to prove that a non-bootstrapped GCC can produce identical binaries to a bootstrapped one (I should post a separate write-up of this somewhere because it's a bit tricky).

- build GCC with `make -O' (as per FS#70871) in order to produce comprehensible log files
- add BOOT_CFLAGS, BOOT_LDFLAGS and LDFLAGS_FOR_TARGET to the make invocation
- while we're at it may as well add STAGE1_CFLAGS as per FS#71476

make -O STAGE1_CFLAGS="-O2" \

I've tested this in a full toolchain bootstrap using latest binutils-2.37, gcc-11.2 and glibc-2.34. The GCC testsuite results are identical as compared to when not building like above. The target libs are all now full RELRO (except for but this has now been fixed on GCC trunk[4]). Overall there are less complaints from namcap.

NOTE: If / when Arch changes the distro defaults in devtools to match current pacman makepkg.conf, certain CFLAGS will need to be filtered out. This is exacly what the Fedora rpm specfile does.

This task depends upon

Comment by Allan McRae (Allan) - Monday, 09 August 2021, 07:55 GMT
Do you happen to have a collection of PKGBUILDs with all your fixes? I happy to review the changes in one go and pass them onto the current toolchain maintainer.
Comment by Toolybird (Toolybird) - Monday, 09 August 2021, 08:34 GMT
Yeah, sure thing. But I'm still workin on it :) I should figure out how to put stuff up on Github or somewhere..
Comment by Toolybird (Toolybird) - Wednesday, 11 August 2021, 06:06 GMT
Attached are some PKGBUILDs as requested. Can provide diffs instead if necessary. I have some other stuff in the pipeline but this is just the bare minimum fixes as recently reported.

Note: I've only build-tested these and run the testsuites in the standard nspawn container. Haven't actually installed the pkgs on a "real" system then built more software. Looking around the 'net, there are some issues with latest binutils and glibc. Subsequent patches will certainly be needed (as is typical for toolchain upgrades).