#63161 closed defect (fixed)
gcc11 / libgcc11: not building for 32bit SnowLeopard ld: illegal text-relocation to ___stack_chk_guard in /usr/lib/libSystem.dylib
Reported by: | kencu (Ken) | Owned by: | kencu (Ken) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | snowleopard | Cc: | |
Port: | libgcc11 gcc11 |
Description
gcc11/libgcc11 is not presently building on SnowLeopard 32bit.
The first error is:
:info:build /opt/local/bin/clang++-mp-9.0 -arch i386 -std=c++11 -g -DIN_GCC -fPIC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -L/opt/local/lib -Wl,-headerpad_max_install_names -no-pie -o build/genhooks \ :info:build build/genhooks.o build/errors.o ../build-i386-apple-darwin10/libiberty/pic/libiberty.a :info:build clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument] :info:build ld: illegal text-relocation to ___stack_chk_guard in /usr/lib/libSystem.dylib from __ZL18emit_documentationPKc in build/genhooks.o for architecture i386
that is a common error with 32bit builds, and can usually be overcome with this:
if {${configure.build_arch} eq "i386"} { configure.env-append LDFLAGS=-Wl,-read_only_relocs,suppress }
However, although that allows genhooks to be built, that leads to a bus error later when it is run:
:info:build build/genhooks -d \ :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc11/libgcc11/work/gcc-11.1.0/gcc/doc/tm.texi.in > tmp-tm.texi :info:build /bin/sh: line 1: 53082 Bus error build/genhooks -d /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc11/libgcc11/work/gcc-11.1.0/gcc/doc/tm.texi.in > tmp-tm.texi :info:build make[3]: *** [s-tm-texi] Error 138 :info:build make[3]: *** Waiting for unfinished jobs....
so that will not be a solution.
Building with gcc-4.8 does work, although it is a bit tricky in our MacPorts configuration because gcc-4.8 is supposed to now use libgcc11 for it's libraries, and so that makes a catch-22, and you need to do some fancy footwork to do this:
$ port -v installed libgcc11 The following ports are currently installed: libgcc11 @11.1.0_2 (active) requested_variants='' platform='darwin 10' archs='i386' date='2021-07-01T17:55:22-0700'
What does seem to work when building with clang-9.0 is forcing pie
off like this:
--- gcc/configure.old 2021-07-01 18:31:32.000000000 -0700 +++ gcc/configure 2021-07-01 18:31:54.000000000 -0700 @@ -31798,7 +31798,7 @@ int main(void) {return 0;} _ACEOF if ac_fn_cxx_try_compile "$LINENO"; then : - gcc_cv_c_no_fpie=yes + gcc_cv_c_no_fpie=no else gcc_cv_c_no_fpie=no fi @@ -31825,7 +31825,7 @@ int main(void) {return 0;} _ACEOF if ac_fn_cxx_try_link "$LINENO"; then : - gcc_cv_no_pie=yes + gcc_cv_no_pie=no else gcc_cv_no_pie=no fi
Just investigating if that approach has any undesired side effects now.
Attachments (1)
Change History (5)
Changed 3 years ago by kencu (Ken)
Attachment: | gcc11-fail-SL-i386.log added |
---|
comment:1 Changed 3 years ago by kencu (Ken)
comment:2 Changed 3 years ago by kencu (Ken)
Owner: | set to kencu |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:3 Changed 3 years ago by catap (Kirill A. Korinsky)
comment:4 Changed 3 years ago by catap (Kirill A. Korinsky)
Note: See
TracTickets for help on using
tickets.
Upstream points this out to be a bug in the 32 bit clang implementation, which it indeed seems to be.
They have a more intricate patch that still allows no-pie to be used where it should be used and fixes the issue...testing now.
It will be harder to maintain that more intricate patch, but it's a better patch.
Older gcc versions may also need that fix to bootstrap with clang 32 bit. Or we can arrange to bootstrap clang with gcc, starting with gcc-4.2 (bootstraps up to gcc10), or gcc-4.8 or gcc-5.0 (bootstraps gcc11+ as well).