[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_gcc]] Here's what's to be done for maintaining GCC. Apart from the target-specific configuration machinery, there shouldn't be any major differences within GCC between the GNU/Hurd and GNU/Linux ports, for example. Especially all the compiler magic is all the same. [[!toc levels=2]] # [[General information|/gcc]] # [[Sources|source_repositories/gcc]] ## Boehm GC GCC includes an own variant of [[/Boehm_GC]] that is based on an upstream version, but with own patches, etc. This is used for Java. (There are patches (apparently not committed) that GCC itself can use it, too: .) Patches to GCC's fork should be contributed back to upstream [[/Boehm_GC]]. [[tschwinge]] reviewed (but only briefly for large parts) the differences on 2010-12-08, based on the [[GCC Git mirror's 8e79e9d43f32c8852f068da91d655297d92ac0f4 (2010-11-29) sources|source_repositories/GCC]] and Boehm GC's CVS HEAD sources from 2010-12-02, converted to [[Git, correspondingly 1c2455988a8f59a5f83b986b9156f03be395b3b6|source_repositories/boehm_gc]]. On 2010-11-17, [[tschwinge]] reviewed the Debian GCC Boehm GC changes, compared them to the upstream code, and put it into the local *hurd/boehm-gc/config_backport* branch, planning to submit it to gcc-patches after testing with the GCC testsuite. * Check * 02e191ba495b4ec87aeb961ff9afdb666287104a * ce062771587f6637ce09f79c36e24de691032919 * a9cc177ef514d6eb39db72c82911fcea2cd70dba * 7b8d306d18986cd98808c9ed5d3a696a186dc213 Looks generally OK. * a3a3fd06ae58af9591a95c94245809b0359289ff Looks OK. * fe5ef4a01870545d0344e670cd528ad096ebab1d OK. # Configuration Last reviewed up to the [[Git mirror's 4b1da543a2212d4b442c4b83b5233469032003d1 (2012-04-11) sources|source_repositories/gcc]]. has documentation for the `configure` switches. * Configure fragments that have `*linux*` cases might/should often contain those for us (and GNU/k*BSD) as well. * `configure.ac` * `libgomp/configure.tgt` * `libstdc++-v3/configure.host` `abi_baseline_pair` etc. setting. * `libstdc++-v3/config/os/gnu-linux/*` Is used for all GNU systems, as per `libstdc++-v3/configure.host`. Should rename to `gnu-user` to reflect this? * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for x86 Linux. (Why?) * `hurd/usr` `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`, [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]]. Debian. * Eventually: get rid of this special-casing. [[!message-id "gckk1s$e0b$1@ger.gmane.org"]]. * [[`libmudflap`|libmudflap]]. * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) be worthwhile w.r.t. our [[multithreaded|multithreading]] libraries? * Also see `libgcc/config/i386/morestack.S`: comments w.r.t `TARGET_THREAD_SPLIT_STACK_OFFSET`; likely needs porting. As per `libgcc/config/i386/t-stack-i386`, the former file is only used for `-fsplit-stack` support -- which is currently enabled for us in `libgcc/config.host`, but not usable via GCC proper. * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't valid for us (yet), I think. * `--enable-languages=[...]` * GNAT is not yet ported / bootstrapped? * The Google Go's libgo (introduced in e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs OS configuration / support. * `--enable-frame-pointer` `gcc/configure.ac`: `enable_frame_pointer=no` * `--with-dwarf2`? * `--enable-werror` * `--enable-checking` * `--enable-linker-build-id` * `--enable-gnu-unique-object` * `--enable-lto`, `--enable-gold` [[binutils_gold]] * `--enable-indirect-function` [[IFUNC]] * , * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or similar. Likewise for `gcc/config/i386/t-linux`. * Debian's GCC package has Hurd-specific patches. Some have been forwarded upstream (and have been ignored). [[Thomas_Schwinge|tschwinge]] is working on getting them integrated. * [\[meta-bug\] bootstrap bugs for \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824) * [build system: gcc\_cv\_libc\_provides\_ssp and NATIVE\_SYSTEM\_HEADER\_DIR](http://gcc.gnu.org/ml/gcc/2008-10/msg00130.html) * [-fstack-protector shouldn't use TLS in freestanding mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838) * Check before/after Joseph changes. (Should be fine.) * 34618b3190c110b8926cc2b1db4b4eac95451995 What's this used for? (Check ML.) Ask to include i686-pc-gnu (once it is buildable out of the box)? See also 73905b5de0d9a086f22ded7638bb1c0ae1b91326. * Various testsuite bits should include `*-*-gnu*`, too. * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's libbid: [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[1]: *** [bid_decimal_globals.o] Error 1 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc' make: *** [all-target-libgcc] Error 2 See threads at [[!message-id "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]], [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id "4D52D522.1040804@gmail.com"]]. Can simply configure the first GCC with `--disable-decimal-float`. Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)? See `generic-nonstrack.c`, for example. The latter (and also `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc` which could be centralized at one place, for example definition of `inhibit_libc`. * [low] [[toolchain/cross-gnu]] The directory that should contain system headers does not exist: /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include make[2]: *** [stmp-fixinc] Error 1 make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj' `mkdir` the directory for now, but what is really going on? GCC has *use `/usr/include` patch*, but glibc still installs into `/include/`? * `__GLIBC__` IRC, freenode, #hurd, 2012-01-05: on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny ?? not from features.h ? in gcc/config/kfreebsd-gnu.h :-) correct, it's enabled in gcc's config i discovered that after banging my head on the wall trying to find out why some stuff wasn't compiling even after kfreebsd porting patches adding preprocessors checks for __GLIBC__ * [low] Does `-mcpu=native` etc. work? (For example, 2ae1f0cc764e998bfc684d662aba0497e8723e52.) * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b * `config/mmap.m4` * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for us? * f29a2041f32773464e226a83f41762c2e9cf658e (e53a96c2136f7cdff4699475fea41afeed9dece3) * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when using __SIGRTMIN`. GCC PR52390. Fixed by 8d2259c83f94c082ad8a00b5d00bb639ce24efce. * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for i?86-linux`. * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed to come from `config/tls.m4:GCC_CHECK_TLS`? # Build Here's a log of a GCC build run; this is from our [[Git repository's 9cfe8751c08b60037c3f36d6d86d164c45fc8ec6 (2011-10-23) sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C $ (cd ../master/ && contrib/gcc_update --touch) $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build [...] $ make 2>&1 | tee log_build_ [...] Different hosts may default to different shells and compiler versions; thus harmonized. This takes up around 3.1 GiB, and needs roughly 2.5 h on kepler.SCHWINGE and 12 h on coulomb.SCHWINGE. ## Analysis $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/log_build $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/log_build $ diff -wu <(sed -f toolchain/logs/gcc/linux/log_build.sed < toolchain/logs/gcc/linux/log_build) <(sed -f toolchain/logs/gcc/hurd/log_build.sed < toolchain/logs/gcc/hurd/log_build) > toolchain/logs/gcc/log_build.diff * [[`checking if gcc static flag -static works... no`|glibc_madvise_vs_static_linking]] Addressed in Debian glibc. * DFP Addressed in *hurd/decimal_floating_point* branch. +configure: WARNING: decimal float is not supported for this target, ignored ... and later on: -checking for decimal floating point... bid +checking for decimal floating point... configure: WARNING: decimal float is not supported for this target, ignored +dpd ... and later on: -checking whether decimal floating point is supported... yes +checking whether decimal floating point is supported... no +configure: WARNING: decimal float is not supported for this target, ignored * `libstdc++-v3/acinclude.m4`: ISO/IEC TR 24733 -checking for ISO/IEC TR 24733 ... yes +checking for ISO/IEC TR 24733 ... no * `--enable-decimal-float`, `--enable-fixed-point`, `--with-long-double-128` `configure: WARNING: decimal float is not supported for this target, ignored` * `libgcc/configure.ac` [might need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be aligned for us to the `*linux*` cases. As well as at the end of `libgcc/config.host`. Check. checking whether decimal floating point is supported... no checking whether fixed-point is supported... no * `host-linux.c` vs. `host-default.c` * *fixincludes* stuff * malloc? -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc` for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`. * *libgomp* * `libgomp/config/linux/`, `libgomp/config/linux/x86` `sed`ed away. * `-ftls-model=initial-exec -march=i486 -mtune=i686` `sed`ed away. * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`. What're they used for? * `RLIMIT_VMEM`. Usage kosher? * `basic_file.cc` +basic_file.cc: In member function 'std::streamsize std::__basic_file::showmanyc()': +basic_file.cc:347:33: warning: enumeral and non-enumeral type in conditional expression [enabled by default] * `libtool: link: ar rc .libs/libstdc++.a [...]` Just different order of object files, or another problem? TODO * `libobjc/encoding.c`: libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...] +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function] * `libobjc/thr.c`: `gcc/gthr-posix.h` libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] +In file included from ../.././gcc/gthr-default.h:1:0, + from [...]/hurd/master/libobjc/../gcc/gthr.h:160, + from [...]/hurd/master/libobjc/thr.c:45: +[...]/hurd/master/libobjc/../gcc/gthr-posix.h: In function '__gthread_objc_thread_set_priority': +[...]/hurd/master/libobjc/../gcc/gthr-posix.h:389:41: warning: unused parameter 'priority' [-Wunused-parameter] * `/proc/self/*` -checking for /proc/self/exe... yes -checking for /proc/self/maps... yes +checking for /proc/self/exe... no +checking for /proc/self/maps... no * GCJ: `java-signal.h`, `java-signal-aux.h` -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h * GCJ: `jni_md.h` -checking jni_md.h support... yes +checking jni_md.h support... configure: WARNING: no * *default library search path* -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 +checking for the default library search path... /lib /usr/lib * `./classpath/[...]/*.properties` Just different order of files, or another problem? * `libjava/gnu/gcj/util/natGCInfo.cc` libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] * `gnu/java/net/natPlainSocketImpl.cc` libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/net/natPlainSocketImpl.cc [...] +gnu/java/net/natPlainSocketImpl.cc: In member function 'virtual jint gnu::java::net::PlainSocketImpl::available()': +gnu/java/net/natPlainSocketImpl.cc:515:27: warning: enumeral and non-enumeral type in conditional expression [enabled by default] * `gnu/java/nio/channels/natFileChannelImpl.cc` libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/nio/channels/natFileChannelImpl.cc [...] +gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'jint gnu::java::nio::channels::FileChannelImpl::available()': +gnu/java/nio/channels/natFileChannelImpl.cc:388:20: warning: enumeral and non-enumeral type in conditional expression [enabled by default] * `libgcj.la` Just different order of object files, or another problem? Is there a pattern that GNU/Hurd hands out the files alphabetically sorted where it wouldn't need to ([[!taglink open_issue_hurd]])? * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` * The following warnings probably appeared when adding `t/debian-multiarch`: gawk -f ../../master/gcc/opt-functions.awk -f ../../master/gcc/opt-read.awk \ -f ../../master/gcc/optc-gen.awk \ -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c +warning: multiple different help strings for I: + -I . Add to the end of the main source path + -I Add to the end of the main include path +warning: multiple different help strings for nostdinc: + Do not look for source files in standard path + Do not search standard system include directories (those specified with -isystem will still be used) * `jar` make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and coulomb.SCHWINGE a GCJ one. There are other instances of this in the following. * *default library search path* -checking for the default library search path... /lib /usr/lib /lib/[MULTIARCH] /usr/lib/[MULTIARCH] /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 +checking for the default library search path... /lib /usr/lib Should be aligned by Samuel's binutils patch. # Install $ make install 2>&1 | tee log_install [...] This takes up around 630 MiB, and needs roughly 4 min on kepler.SCHWINGE and 35 min on coulomb.SCHWINGE. ## Analysis $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/log_install $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/log_install $ diff -wu <(sed -f toolchain/logs/gcc/linux/log_install.sed < toolchain/logs/gcc/linux/log_install) <(sed -f toolchain/logs/gcc/hurd/log_install.sed < toolchain/logs/gcc/hurd/log_install) > toolchain/logs/gcc/log_install.diff * `libtool: finish`: `ldconfig` is not run for the Hurd. [[libtool]]. * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) * `value-unwind.h` /usr/bin/install -c -m 644 ../../master/gcc/../libcpp/include/symtab.h [...]/hurd/master.build.install/lib/gcc/[ARCH]/4.7.0/plugin/include/symtab.h -/usr/bin/install -c -m 644 ../../master/gcc/../libgcc/config/i386/value-unwind.h [...]/hurd/master.build.install/lib/gcc/[ARCH]/4.7.0/plugin/include/value-unwind.h /usr/bin/install -c -m 644 ../../master/gcc/ada/gcc-interface/ada-tree.def [...]/hurd/master.build.install/lib/gcc/[ARCH]/4.7.0/plugin/include/ada/gcc-interface/ada-tree.def Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. * `jar`: as above. # Testsuite Testing on GNU/Hurd is blocked on [[fork_mach_port_mod_refs_ekern_urefs_owerflow]]. TODO. Can use parallel testing, see [[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. $ make -k check-gcc 2>&1 | tee log_check [...] This needs roughly 3.75 h on kepler.SCHWINGE and 24 h on coulomb.SCHWINGE. $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/*/*/*/*.sum | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/sum $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/*/*/*/*.sum | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/sum $ diff -u -F ^Running toolchain/logs/gcc/linux/sum toolchain/logs/gcc/hurd/sum > toolchain/logs/gcc/sum.diff ## Analysis TODO. # Specific Languages * [[GNAT]] * [[gccgo]]