[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 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. # Configuration Last reviewed up to the [[Git mirror's 16774908cf3453bfa0d7142e377539b0a80512f0 (2011-07-05) 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` * `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 * `libgomp/configure.tgt` * `libstdc++-v3/config/os/gnu-linux/*` * Etc. * [[`libmudflap`|libmudflap]]. * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) be worthwhile w.r.t. our multithreaded libraries? * , * `--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-build-with-cxx` * `--enable-decimal-float`, `--enable-fixed-point`, `--with-long-double-128` `configure: WARNING: decimal float is not supported for this target, ignored` * `--enable-linker-build-id` * `--enable-gnu-unique-object` * `--enable-lto`, `--enable-gold` [[binutils_gold]] * `--enable-indirect-function` [[IFUNC]] * bdd793b231c5454437e28d91ecda885a83819e66, 2010-12-23, `dl_iterate_phdr`: `cross-gnu` says: `checking dl_iterate_phdr in target C library... unknown` Patch also contains `#if defined __linux__`, which likely should be glibc-specific. * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or similar. Likewise for `gcc/config/i386/t-linux`. * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't valid for us (yet), I think. * 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. * 1e53920f848bded45425cf0ed9de9e77d5948c1d (fixed in *linux-unwind.h* branch) Now unconditionally uses the Linux i386/linux-unwind.h on non-Linux x86 architectures in libgcc. Due to `#ifdef` removal in unwind-dw2.c, the header file will always be included. There is now an empty no-unwind.h, which is the default unless overridden. The solutions should be in libgcc/config.host to not set md_unwind_header for non-Linux x86. [Discussion](http://gcc.gnu.org/ml/gcc-patches/2011-06/threads.html#01571). * [low, testsuite] 5c7992866145620ffd0bc75b4f23298162b2c17f `check_effective_target_pie` should include `*-*-gnu*`, too. # Build Here's a log of a GCC build run; this is from our [[Git repository's 5ac39af7792ba0dc363cc199060faf53dfa9dc1a (2010-12-08) sources|source_repositories/gcc]], run on kepler.SCHWINGE and grubber. $ export LC_ALL=C $ ../master/configure --prefix="$PWD".install 2>&1 | tee log_build [...] $ make SHELL=/bin/bash 2>&1 | tee log_build_ [...] (kepler.SCHWINGE defaults to using /bin/sh, grubber to /bin/bash; thus harmonized.) On grubber, this needs roughly 24 hours, and takes up around 2.5 GiB. ## Analysis $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_build* | sed -e "s%${PWD}%[...]%g"' | sed -f open_issues/gcc/log_build-linux.sed) <(ssh grubber 'cd tmp/gcc/ && cat hurd/master.build/log_build* | sed "s%${PWD}%[...]%g"' | sed -f open_issues/gcc/log_build-hurd.sed) > open_issues/gcc/log_build-diff [[log_build-diff]]. * [[`checking if gcc static flag -static works... no`|glibc_madvise_vs_static_linking]] * DFP +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 * `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 * *libgomp* * `libgomp/config/linux/`, `libgomp/config/linux/x86` * `-ftls-model=initial-exec -march=i486 -mtune=i686` * `-static` vs. `dlopen` -checking whether a statically linked program can dlopen itself... no +checking whether a statically linked program can dlopen itself... yes * ISO/IEC TR 24733 -checking for ISO/IEC TR 24733 ... yes +checking for ISO/IEC TR 24733 ... no * `basic_file.cc` +basic_file.cc: In member function 'std::streamsize std::__basic_file::showmanyc()': +basic_file.cc:344: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? * `gcc/gthr-posix.h` +In file included from ../.././gcc/gthr-default.h:1:0, + from [...]/hurd/libobjc/../gcc/gthr.h:162, + from [...]/hurd/libobjc/thr.c:43: +[...]/hurd/libobjc/../gcc/gthr-posix.h: In function '__gthread_objc_thread_set_priority': +[...]/hurd/libobjc/../gcc/gthr-posix.h:384:41: warning: unused parameter 'priority' [-Wunused-parameter] * `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 * `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/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib +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` +../../../hurd/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../hurd/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../hurd/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] * `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` +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`, `.libs/libgcj.a` 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]])? Why does the GNU Hurd's `lib_build_` repeatedly contain a long series (several KiB) of NUL (0) characters after the 5319th column in the `/bin/bash ./libtool --tag=CXX --mode=link [...] -o libgcj.la [...]` command line? Is that only in the log? * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` # Install $ make SHELL=/bin/bash install 2>&1 | tee log_install [...] (kepler.SCHWINGE defaults to using /bin/sh, grubber to /bin/bash; thus harmonized.) On grubber, this needs roughly 15 minutes, and takes up around 0.7 GiB. ## Analysis $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_install | sed -e "s%${PWD}%[...]%g" -e "s%i686-pc-linux-gnu%[ARCH]%g"') <(ssh grubber 'cd tmp/gcc/ && cat hurd/master.build/log_install | sed -e "s%${PWD}%[...]%g" -e "s%i686-unknown-gnu0\.3%[ARCH]%g"') > open_issues/gcc/log_install-diff [[log_install-diff]]. * `libtool: finish`: `ldconfig` is not run for the Hurd. * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) # Testsuite $ make SHELL=/bin/bash -k check 2>&1 | tee log_check [...] Blocked on [[fork_mach_port_mod_refs_ekern_urefs_owerflow]]. ## Analysis # Specific Languages * [[GNAT]] * [[gccgo]]