script: do not modify CFLAGS in set_cross_vars

[kolyshkin]

This is an alternative to #5456.

When cross-building libseccomp, build_libseccomp resets CFLAGS to an empty value (if it was unset) before each architecture, and set_cross_vars exports it. Autoconf only applies its default CFLAGS (-g -O2) when CFLAGS is unset, so the per-architecture libseccomp builds (which release binaries link against, including for the native architecture) end up unoptimized. See #5456 for performance numbers.

The only reason CFLAGS was touched at all is that set_cross_vars puts -m32 -march=... there for 386, which is why callers had to save and restore it. Pass these flags via CC instead (as autoconf documentation suggests for multilib builds), so set_cross_vars no longer modifies CFLAGS, and remove the now-unneeded save/restore from both build-seccomp.sh and release_build.sh.

This way, a user-provided CFLAGS is passed as is, and if it is unset, configure uses its defaults for all architectures, including 386 (which #5456 does not fix, since set_cross_vars makes CFLAGS non-empty there).

Tested libseccomp 2.6.0 configure (on Debian trixie) with the new set_cross_vars:

• 386: CC='x86_64-linux-gnu-gcc -m32 -march=i686', CFLAGS='-g -O2';
• amd64: CC='x86_64-linux-gnu-gcc', CFLAGS='-g -O2'.

[cyphar]

Little worried that "$CC" foo will now break in non-obvious ways and only when building x86 binaries. :/

[kolyshkin]

I dunno, info autoconf says (in CFLAGS description):

If it affects only the compiler proper, ‘CFLAGS’ is the natural home for it. If an option affects multiple phases of the compiler, though, matters get tricky:

• If an option selects a 32-bit or 64-bit build on a bi-arch system, it must be put direcly into ‘CC’, e.g., ‘CC='gcc -m64'’. This is necessary for ‘config.guess’ to work right.
• Otherwise one approach is to put the option into ‘CC’. Another is to put it into both ‘CPPFLAGS’ and ‘LDFLAGS’, but not into ‘CFLAGS’.

this is exactly what we do here.

[kolyshkin]

Ah if you mean if we'll quote $CC and it will fail in a non-obvious way -- I think it will fail in a very obvious way, saying something like:

bash: gcc -m32 -march=i686: command not found...

[cyphar]

I mean, if autoconf says to do that then who am I to argue?