Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 545052

Summary: multilib: Support for different CFLAGS for different ABIs
Product: Gentoo Linux Reporter: Matthias Schwarzott <zzam>
Component: EclassesAssignee: Michał Górny <mgorny>
Status: CONFIRMED ---    
Severity: normal CC: ald, jasmin+gentoo, marcan, matthew, mgorny, mrpippy, tetromino
Priority: Normal    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Matthias Schwarzott gentoo-dev 2015-03-30 11:49:20 UTC
I want to have different CFLAGS for amd64 and x86 ABI.

What I want for amd64 is:
CFLAGS="-march=native -O2 -pipe -ggdb"

For x86 I need to additionally have "-mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" to support running 32bit applications under valgrind.

This works mostly, but I was told that it is not supported:
CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2"
CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2"

E.g. it breaks mariadb and other packages, see bug 541616.
Comment 1 Alex Dubenetsky 2015-05-09 11:39:19 UTC
I also vote for this.

I have two reasons for it:
1) I'm not a gcc-guru, but I think this is not the rule, that safe x86 flags and safe x86_64 flags are the same. (I guess for other arches it's also true.)
Limiting to use for many ABIs the same flags we probably left away some good flags than can be safely used for one of ABI.
IMHO, specifying one set of flags for two (or more) ABIs we creating an addition limit without any kind of "profit".
2) Recently, we was turned from use emul-linux* to use native multilib support, that's great, but someone who played with CFLAGS
actually should experienced with the problem, that emul-linux* was build with some flags, different from the system flags, and there is no way
to specify for x86 that 'old' flags and return it to the way it was. (I don't know how many people really faced with it, but, for example, I did: I used "-msseregparm" flag
for x86_64 for couple of years, and it was more or less ok, but this flag is really bad for x86[32]. And now it's impossible to use it at all, 
because now I need to find safe flags for both ABIs.)

May be we can think about adding CFLAGS_${ABI}, which will really be a CFLAGS for exact ABI?

Just an idea how that could be done:
1) rename old CFLAGS_${ABI} -> CABI_${ABI} (or TABI_${ABI} or CTARGET_ABI_${ABI} or something else more suitable)
2) re-add new CFLAGS_${ABI} in meaning it's a really more specific CFLAGS, added after common (global) CFLAGS,
and NOT suppressed for default ABI.
3) start some migration period, say a year. At that period add to related system staff, like gcc-config package
a check, if there is the new var is available - then use it, otherwise use the old one.
4) for migration period set up by default both old and new var to the same value. This can allow us to avoid version conflicts
between portage and staff like gcc-config. At the same time from this point it will be able use new CFLAGS_${ABI}.
5) close migration period, remove unneeded extra code. If someone skipped that period, no problem - temporary addition to make.comf
CFLAGS_x86="-m32" (or some other old var with appropriate value) will solve possible world update issues.

As result, for example for gcc, that could be like this:

gcc ... CABI_${ABI} ... CFLAGS CFLAGS_${ABI} ...

PS
May be I want to much, but I think that's the better, right and strict way to use CFLAGS.
Right now CFLAGS_${ABI} are formally a compiler flags, but actually it's more a hint to the compiler to build code for specific ABI...
Comment 2 Hector Martin 2016-04-22 16:51:45 UTC
Ping, this really needs some sort of solution. Without it, 32-bit valgrind is unusable. I tried setting CFLGAS_x86 like Matthias did, but also found breakage, though with a rather small set of packages - it mostly worked as intended, but on my system it broke mariadb and graphite2, building them as 64-bit instead.

Since the set of affected packages is relatively small, perhaps it makes sense to fix whatever is broken and make it a supported configuration option? For graphite2, it looks like a bad interaction with the CMake toolchain stuff ends up stripping the CFLAGS_x86 entirely if they are not "-m32" (perhaps if there is more than one argument included).
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-03-13 06:48:01 UTC
Can you still reproduce the problems with overriding CFLAGS_x86? I think I've fixed handling >1 flag in cmake-utils at some point.
Comment 4 Matthew Dawson 2018-03-16 03:29:07 UTC
(In reply to Michał Górny from comment #3)
> Can you still reproduce the problems with overriding CFLAGS_x86? I think
> I've fixed handling >1 flag in cmake-utils at some point.

Is CFLAGS_x86 now (officially?) supported?  From bug 541616, it appeared not to be the case.

So far in my limited set of builds to make steam games run, it hasn't crashed.  I did a test compile of libssh with an extra flag in CFLAGS_x86 and it appeared to work.

If CFLAGS_x86 is going to become officially supported, is it going to remain necessary to keep -m32 in it manually?  Or is it always going to be required if we want to modify it?  I don't mind either way (and I can see uses cases either way), but I wouldn't mind trying to help if that will change.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-03-16 07:40:29 UTC
I'm researching the possible options, and this is probably going to make most sense.
Comment 6 Ostashevskyi Viktor 2020-01-13 12:06:33 UTC
Hello,

Any progress with this?

Here is my use-case: I want to build 32-bit libraries with '-mstackrealign', so it will be possible to run old binaries compiled with GCC < 4.5, before ABI breakage regarding default stack alignment (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838).