Add GCC 14.1.0.

[guyutongxue]

Sorry for a so big PR, but it might be necessary to change these files.

Here is what it does:

• Add build scripts for gcc-14.1.0 and gcc-14-branch;
• Bump expat version (this suppresses #671 and fixes #672), because v2.5.0 no longer available to download due to vulnerability;
• Because GCC 14 starts to following ISO C standard strictly (and do not connivance "traditional" K&R C features like implicit function declaration etc.), some sub-targets failed when building with the newly-built GCC 14. That's why more changes are made:
• A test file modified.
• Upgrade gdb to 14.2. (Original version failed under GCC 14)
• Sub-target termcap and python-3 needs CFLAGS like -fpermissive or -Wno-error=implicit-function-declaration now.
• For python-3, an additional patch applied.
• For termcap, an additional patch applied (wtf the original Makefile do not use CFLAGS); AND ALSO, change the way to pass CFLAGS etc. to the configure script.
  • The original configure script doesn't recognize FOO=bar in command line arguments as environment variable (that's why in previous version, those CFLAGS settings are commented out).
  • I change the code to deal with PKG_CONFIGURE_FLAGS in func_configure, so that CFLAGS etc. are exported as environment variables instead of passing them as command line arguments.
  • In order to keep the PKG_CONFIGURE_FLAGS array structure as-is, now I'm using -n flag (a.k.a. pass array argument by reference) that supports from Bash 5.3 (ref, and ref). As a benefit, we can now remove all extra "escaped quotation mark" in *FLAGS settings.

I've tested these changes and successfully built GCC 14.1.0 with SEH, Win32, UCRT and v11 runtime. Let's wait for GitHub Actions' result.

[starg2]

You might want to update .github/workflows/build_cmake.yml and func_map_gcc_name_to_gcc_version in library/functions.sh as well.

• Sub-target termcap and python-3 needs CFLAGS like -fpermissive or -Wno-error=implicit-function-declaration now.

Is it possible to actually fix code rather than silencing warnings?

[guyutongxue]

You might want to update .github/workflows/build_cmake.yml and func_map_gcc_name_to_gcc_version in library/functions.sh as well.

Fixed, thanks!

Is it possible to actually fix code rather than silencing warnings?

Sure we can make many patches instead of silence warnings. But analyzing these errors is, somehow, quite difficult. For example in termcap, we don't have free declaration because <stdlib.h> not included, and that's because STDC_HEADERS is not defined, and that's because in Autoconf, AC_STDC_HEADERS will set ac_cv_header_stdc=no if we are cross-compiling (sad). That's just one error. In python-3, there are too many errors like this (and some errors about pointer const-ness is really hard to fix).

On the other hand, If we add (unnecessary) patches today, we will have more work to do in the future: maintaining these patches once the upstream has update. That's not what I expected, at least -- I just want a stable build script, that means updating packages should be an easy work.

At least, one may think these "-Wno-error" introduce some "bad smell"... probably yes, but actually it does not change anything from previous version since it just makes implicit options explicit.

[starg2]

At least, one may think these "-Wno-error" introduce some "bad smell"... probably yes, but actually it does not change anything from previous version since it just makes implicit options explicit.

Fair enough.