mirror of
git://sourceware.org/git/glibc.git
synced 2024-11-27 03:41:23 +08:00
b1176270de
Every so often we get libsanitizer or libgo builds breaking with new glibc because of some change in the glibc headers. glibc's build-many-glibcs.py deliberately disables libsanitizer and GCC languages other than C and C++ because the point is to test glibc and find glibc problems (including problems shown up by new compiler warnings in new GCC), not to test libsanitizer or libgo; if the compiler build fails because of libsanitizer or libgo failing to build, that could hide the existence of new problems in glibc. However, it seems reasonable to have a non-default mode where build-many-glibcs.py does build those additional pieces, which this patch adds. Note that I do not intend to run a build-many-glibcs.py bot with this new option. If people concerned with libsanitizer, libgo or other potentially affected GCC libraries wish to find out about such problems more quickly, they may wish to run such a bot or bots (and to monitor the results and fix issues found - obviously there will be some overlap with issues found by my bots not using that option). Note also that building a non-native Ada compiler requires a sufficiently recent native (or build-x-host, in general) Ada compiler to be used, possibly more or less the same version as being built. That needs to be in the PATH when build-many-glibcs.py --full-gcc is run; the script does not deal with setting up such a compiler (or any of the other host tools needed for building GCC and glibc, beyond the GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need to keep updating such a compiler manually when running a bot. Tested by running build-many-glibcs.py with the new option, with mainline GCC. There are build failures for various configurations, which may be of interest to Go / Ada people even if you're not interested in running such a bot: * mips64 / mips64el (all configuration): ICE building libstdc++, as seen without using the new option <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>. * aarch64_be: error building libgo (little-endian aarch64 works fine): version.go:67:13: error: expected ';' or ')' or newline 67 | BigEndian = | ^ version.go:67:3: error: reference to undefined name 'BigEndian' 67 | BigEndian = | ^ * arm (all configurations): error building libgo: /scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap' 29 | if randomTrap == 0 { | ^ /scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap' 38 | r1, _, errno := syscall.Syscall(randomTrap, | ^ What's happening there is, I think, that the arm*b*-*-* case in libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with the 'b' in the vendor part, and then something else is failing to handle GOARCH=armbe. Given that you can have configurations with multilibs of both endiannesses, endianness should always be detected by configure.ac, for all architectures, using a compile test of whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual matches to the host (= target at top-level) triplet. * armeb (all configurations): error building libada (for some reason the Arm libada configuration seems to do different things for EH for big-endian, which makes no sense to me and doesn't actually work): a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)" a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)" * hppa: error building libgo (same error as for aarch64_be). * ia64: ICE building libgo. I've filed <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this. * m68k: ICE in the Go front end building libgo <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>. * microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada for lack of a libada port to those systems (I'm not sure sh3 would actually need anything different from sh4): a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47 * i686-gnu: build failure in libada, might be fixed by the patch attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103> (not tested): terminals.c:1115:13: fatal error: termio.h: No such file or directory * scripts/build-many-glibcs.py (Context.__init__): Add full_gcc argument. (Config.build_gcc): Use --disable-libsanitizer for first GCC build, but not for second build if --full-gcc. Use --enable-languages=all for second build if --full-gcc. (get_parser): Add --full-gcc option. (main): Update call to Context. |
||
|---|---|---|
| .. | ||
| abi-versions.awk | ||
| abilist.awk | ||
| backport-support.sh | ||
| build-many-glibcs.py | ||
| check-c++-types.sh | ||
| check-execstack.awk | ||
| check-initfini.awk | ||
| check-installed-headers.sh | ||
| check-local-headers.sh | ||
| check-localplt.awk | ||
| check-textrel.awk | ||
| config-uname.sh | ||
| config.guess | ||
| config.sub | ||
| cpp | ||
| cross-test-ssh.sh | ||
| documented.sh | ||
| evaluate-test.sh | ||
| firstversions.awk | ||
| gen-as-const.awk | ||
| gen-libc-abis | ||
| gen-libc-modules.awk | ||
| gen-posix-conf-vars.awk | ||
| gen-py-const.awk | ||
| gen-rrtypes.py | ||
| gen-sorted.awk | ||
| gen-tunables.awk | ||
| install-sh | ||
| lib-names.awk | ||
| list-fixed-bugs.py | ||
| list-sources.sh | ||
| localplt.awk | ||
| merge-test-results.sh | ||
| mkinstalldirs | ||
| move-if-change | ||
| output-format.sed | ||
| pylint | ||
| pylintrc | ||
| rellns-sh | ||
| soversions.awk | ||
| sysd-rules.awk | ||
| test_printers_common.py | ||
| test_printers_exceptions.py | ||
| test-installation.pl | ||
| update-abilist.sh | ||
| update-copyrights | ||
| versionlist.awk | ||
| versions.awk | ||