Removal of 'struct ucontext' in glibc 2.26 broke gcc-3.3.6 compile (see https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27struct_ucontext.27 ) - a patch for this is attached (to be applied after 05_all_gcc-3.3.x-siginfo.patch from gentoo patchset 1.9, which fixes a similar removal issue). Furthermore, the install phase fails due to an issue with the libtool shell scripts generated in libstdc++3 during the compile phase, which does not recognize the shell to run the install-sh any more. A workaround for the same issue was implemented in the toolchain eclass for the configure phase. The second attached patch implements the same workaround for the compile phase as well. Reproducible: Always
Created attachment 544754 [details, diff] Addition of the CONFIG_SHELL variable for the compile phase This patch for toolchain.eclass adds the CONFIG_SHELL variable to the compile phase as was done before during the configure phase.
Created attachment 544756 [details, diff] Fix for removal of struct ucontext in glibc 2.226
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=57827a2dbb31f225eaeb61a296fdbf0d49c88dc5 commit 57827a2dbb31f225eaeb61a296fdbf0d49c88dc5 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-09-15 18:45:48 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-09-15 18:45:48 +0000 3.3.6: Fix for removal of struct ucontext in glibc 2.26 Fix by Christian Schmidt. Bug: https://bugs.gentoo.org/664486 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> 3.3.6/gentoo/89_all_gcc-3.3.x-ucontext.patch | 58 ++++++++++++++++++++++++++++ 3.3.6/gentoo/README.history | 2 + 2 files changed, 60 insertions(+)
Thanks for the patches! I've queued gcc-2.26 ustat patch for next patchset. Meanwhile you can drop a patch into /etc/portage/patches as a workaround. Can you clarify how lack of CONFIG_SHELL patch breaks for you? Preferably with a build log. It seems to work fine here.
The error that CONFIG_SHELL causes happens in the install phase for me. The error looks like this: make[5]: Entering directory '/tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++' /bin/bash /tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/work/gcc-3.3.6/libstdc++-v3/../mkinstalldirs /tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/image//usr/lib/../lib32 /bin/bash ../libtool --mode=install /bin/bash /tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/work/gcc-3.3.6/install-sh -c libsupc++.la /tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/image//usr/lib/../lib32/libsupc++.la libtool: install: `/tmp/portage2/portage/sys-devel/gcc-3.3.6-r2/image//usr/lib/../lib32/libsupc++.la' is not a directory Try `libtool --help --mode=install' for more information. and is caused by libtool not recognising the /bin/bash parameter as a shell (and in consequence assumes it is the actual install command), and assuming it is told to install multiple source files into a directory. This is what setting the CONFIG_SHELL variable fixes. I am pretty sure this is caused by gcc's multi stage building, which causes configure to be run also during the compile phase. While CONFIG_SHELL is set during the configure phase, configuring the stage 1 compiler, it's not (yet) set during the compile phase, and thus for stage 2 and onward.
Created attachment 547076 [details] failed emerge lof for install phase
Comment on attachment 547076 [details] failed emerge lof for install phase It's gziped.
Oh, now get it. Your fix makes sense . Thank you! gcc-3.4.6 (works, automake-1.7) uses the install tool directly: /bin/bash ../libtool --mode=install /usr/lib/portage/python3.6/ebuild-helpers/xattr/install -c libsupc++.la /tmp/portage/sys-devel/gcc-3.4.6-r2/image//usr/lib/../lib32/libsupc++.la gcc-3.3.6 (fails, automake-1.4) uses unquoted definition of 'bash foo': /bin/bash ../libtool --mode=install /bin/bash /tmp/portage/sys-devel/gcc-3.3.6-r1/work/gcc-3.3.6/install-sh -c libsupc++.la /tmp/portage/sys-devel/gcc-3.3.6-r1/image//usr/lib/../lib32/libsuc++.la
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=add23a64e7eb4d27bed13f10228721270b83a37f commit add23a64e7eb4d27bed13f10228721270b83a37f Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-09-30 12:08:22 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-09-30 12:13:46 +0000 toolchain.eclass: pass CONFIG_SHELL to emake, bug #664486 Christian reports 'make install' failure caused by limitation of ancient autotools in detecting CONFIG_SHELL: ``` /bin/bash .../gcc-3.3.6/libstdc++-v3/../mkinstalldirs \ .../gcc-3.3.6-r2/image//usr/lib/../lib32 /bin/bash ../libtool --mode=install /bin/bash .../gcc-3.3.6/install-sh \ -c libsupc++.la .../gcc-3.3.6-r2/image//usr/lib/../lib32/libsupc++.la libtool: install: `.../gcc-3.3.6-r2/image//usr/lib/../lib32/libsupc++.la' \ is not a directory ``` We already pass CONFIG_SHELL to top-level ./configure. The workaround is to pass CONFIG_SHELL variable to 'make' as well. Reported-by: Christian Schmidt Fixed-by: Christian Schmidt Bug: https://bugs.gentoo.org/664486 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a07d5b3586456a0e8abd66c65c70933d39f7a6af commit a07d5b3586456a0e8abd66c65c70933d39f7a6af Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-09-30 17:27:16 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-09-30 18:38:57 +0000 sys-devel/gcc: cut 1.10 patchset for 3.3.6 Three new patches: + 89_all_gcc-3.3.x-ucontext.patch: Port to glibc-2.26, Fix by Christian Schmidt + 90_all_libtool-pass-all.patch: fix auto-detection of -lc and -lm by libtool + 91_all_libexec-gcc-binutils.patch: add /usr/libexec/gcc/<TARGET> for executables (STANDARD_LIBEXEC_PREFIX) Closes: https://bugs.gentoo.org/664486 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Package-Manager: Portage-2.3.50, Repoman-2.3.11 sys-devel/gcc/Manifest | 1 + sys-devel/gcc/gcc-3.3.6-r2.ebuild | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=4fc910bbdb638f7dc4c0cbc2eb560d5943a05cdb commit 4fc910bbdb638f7dc4c0cbc2eb560d5943a05cdb Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-06-01 10:00:03 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-06-01 10:00:03 +0000 3.4.9: cut 1.9 patchset Two new patches: 91_all_ucontext-to-ucontext_t.patch: fix libjava build on modern glibc 92_all_libtool-pass-all.patch: Unbreak libc and libm detection by libtool when those are linker scripts. Bug: https://bugs.gentoo.org/664486 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> 3.4.6/gentoo/README.history | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
