Setup general CFLAGS

[jdemeyer]

The current way how Sage handles CFLAGS is quite bad. There are several issues:

1. Too many spkg-install files are trying to do clever stuff to determine CFLAGS. This should be done just once instead of in every spkg. This would imply we don't need to handle SAGE64 and SAGE_DEBUG in every spkg.

2. Sometimes, the spkg determines CFLAGS which result in a failed build, for example when the gcc issues instructions which the assembler doesn't know about.

3. Some packages don't do anything clever and just build with simple, suboptimal CFLAGS.

My impression is that MPIR is very good at determining the right CFLAGS. So we should not try to reinvent the wheel, just take MPIR's CFLAGS.

CC: @kini

Component: build

Issue created by migration from https://trac.sagemath.org/ticket/12890

[nexttime]

comment:1

There are a lot of aspects to this, i.e., one could write a whole essay on it, that's why I haven't [yet] replied on #11616...

The introduction of SAGE64 (including its name) was IMHO a poor idea, or at least badly implemented.

Michael Abshoff had some ideas regarding "standard" variables like CC, CFLAGS etc.; see his old wiki page.

The Sage library (i.e., devel/sage/setup.py) should by itself make sure -fno-strict-aliasing is used to compile Cython-generated code when needed and supported.

Sage's configure doesn't configure anything, nor does it take a --target option. (It could for example also set things like EGREP.)

There's in principle no way to determine in an spkg-install whether the settings of CC, LD, CXXFLAGS etc. originate from Sage (currently mostly sage-env) or the user.

Spkgs are intended to make Sage modular (i.e., they're not supposed to be tied to a specific Sage version); they can [currently] rely on a few basic environment variable settings, but not more, and there's currently no framework for an spkg to require a minimal or specific version of Sage or other spkgs.

The assembler errors ("unknown instruction") are almost exclusively caused by the GCC spkg, since any reasonable operating system or distribution ships a toolchain where parts "match". (A user could of course also install a newer compiler without updating binutils etc., but then it's mainly his fault, and we certainly cannot catch and work around all possible issues.) Note that one usually also needs current versions of gdb and valgrind to debug code which exploits newer CPU features.

MPIR implements much more in assembly than other spkgs do, hence it's less likely that GCC is tempted to emit fancy instructions for MPIR's (high-level) C code. (And MPIR uses its own assembler for its "hand-written" assembly files. We might install yasm into Sage if we also build GCC.)

Still a couple of spkgs (i.e., mostly upstream) ignore CC, CXX, CFLAGS etc., or use some non-standard variables for similar or the same purposes, or even abuse CPP and/or CPPFLAGS.

...

[nexttime]

comment:2

P.S.: The situation with Fortran is even worse. We have a useless sage_fortran script and SAGE_FORTRAN* variables, instead of using FC (or F77), FFLAGS, FCFLAGS and LDFLAGS etc.

[mkoeppe]

comment:8

outdated, should close

[fchapoton]

comment:9

indeed