libgcc7 fails to compile (ld: illegal text-relocation to ___cpu_indicator_init)

[rmottola (Riccardo)]

On Leopard i386 I get:

ld: warning: could not create compact unwind for __Unwind_RaiseException: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: non-standard register 0 being saved in prolog
ld: illegal text-relocation to ___cpu_indicator_init in cpuinfo_s.o from anon in cpuinfo_s.o for architecture i386
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.dylib] Error 1
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/i386-apple-darwin9/libgcc'

[rmottola (Riccardo)]

build log Leopard i386

[kencu (Ken)]

There is an ldflag no compact unwind that may be useful

[rmottola (Riccardo)]

I searched on the net and the issues affects several also on newer macs. The option would be:

-Wl,-no_compact_unwind

but if I try to add that, configure fails because ld says "unknown option" and indeed "man ld" on my 10.5 shows nothing thereof. Perhaps we should redirect to another linker? Info: the port is compiling with standard apple gcc-4.2

[rmottola (Riccardo)]

I think the unwinding warnings are not fatal, but the text-relocation about cpu_indicator_init is. I added

-Wl,-read_only_relocs,suppress

but it did not help.

[kencu (Ken)]

You're not alone; I've been seeing similar on i386 builds on our older systems. It has been holding me back from updating gcc on 10.5 to gcc8, and gcc on 10.6 to gcc9.

I think it has to do with the way cctools is now using clang as the assembler, but I'm not 100% certain yet.

[kencu (Ken)]

I continue to be unable to upgrade gcc7 on Leopard.

Perhaps I might opine that given that gcc7 is basically only useful on Tiger and Leopard, where it is the go-to compiler, it might be an idea to make sure that it actually builds on those systems before pushing an update through. But that's just me.

[rmottola (Riccardo)]

GCC7 as a whole compiler did build and work, the issue is with "other" tools that somehow changed... most probably the linker or some other cctools option. DO you think we can "force" it to use the linker without clang? (This issue, btw, could be in other things I try to build and have linking issues)

[kencu (Ken)]

we have our build of gcc7 fixed on PPC now, so I'll work on i386 next.

[kencu (Ken)]

fixed locally...now for a general fix perhaps...

$ port -v installed | grep gcc7
  gcc7 @7.5.0_0 (active) platform='darwin 9' archs='i386' date='2019-12-01T01:12:59-0800'
  libgcc7 @7.5.0_0 (active) platform='darwin 9' archs='i386' date='2019-11-30T23:51:56-0800'

[kencu (Ken)]

Here's what I did, Riccardo. Not sure if every bit of this is needed. I just did it all and gcc7/libgcc7 built. Now to see if just doing some subset of this is sufficient to fix it.

$ git diff --no-index /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/gcc7 ./
diff --git a/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/gcc7/Portfile b/./Portfile
index 27bf288..268b8de 100644
--- a/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/gcc7/Portfile
+++ b/./Portfile
@@ -94,10 +94,6 @@ configure.args      --enable-languages=c,c++,objc,obj-c++,lto,fortran \
                     --disable-multilib \
                     --enable-lto \
                     --enable-libstdcxx-time \
-                    --with-build-config=bootstrap-debug \
-                    --with-as=${prefix}/bin/as \
-                    --with-ld=${prefix}/bin/ld \
-                    --with-ar=${prefix}/bin/ar \
                     --with-bugurl=https://trac.macports.org/newticket
 
 # see https://lists.macports.org/pipermail/macports-dev/2017-August/036209.html
@@ -105,18 +101,6 @@ configure.args      --enable-languages=c,c++,objc,obj-c++,lto,fortran \
 # it only determines how std::call_once works
 configure.args-append \
                     --disable-tls
-
-configure.env-append \
-                    AR_FOR_TARGET=${prefix}/bin/ar \
-                    AS_FOR_TARGET=${prefix}/bin/as \
-                    LD_FOR_TARGET=${prefix}/bin/ld \
-                    NM_FOR_TARGET=${prefix}/bin/nm \
-                    OBJDUMP_FOR_TARGET=${prefix}/bin/objdump \
-                    RANLIB_FOR_TARGET=${prefix}/bin/ranlib \
-                    STRIP_FOR_TARGET=${prefix}/bin/strip \
-                    OTOOL=${prefix}/bin/otool \
-                    OTOOL64=${prefix}/bin/otool
-
 pre-configure {
     configure.args-append --with-pkgversion="MacPorts ${name} ${version}_${revision}${portvariants}"
 
@@ -359,12 +343,21 @@ configure.env-append \
 build.env-append \
     "CPP=${configure.cc} -E" \
     "CXXCPP=${configure.cxx} -E"
-
-# gcc default optflags are required to build gcc7 with older compilers
-# see https://trac.macports.org/ticket/59706
-# we probably also want to clear out the rest of the configure.XYZ flags
+
 configure.optflags
 
+if {${os.major} < 10} {
+    pre-configure {
+        xinstall -d ${workpath}/tools
+        set tools {nm as ar otool ranlib lipo libtool segedit strip size strings ld ld64}
+         foreach tool $tools {
+             ln -s /usr/bin/$tool ${workpath}/tools/$tool 
+         }
+    }
+    configure.env-append PATH=${workpath}/tools:${env(PATH)}
+    build.env-append     PATH=${workpath}/tools:${env(PATH)}
+}
+
 configure.cc-append [get_canonical_archflags]
 configure.cc_archflags
 configure.cxx-append ${configure.cxx_archflags}

[kencu (Ken)]

It is looking like the one key part of this is just this:

--with-as=${prefix}/bin/as

and that needs to be this

--with-as=/usr/bin/as

to ensure that the older gas assembler is used, and not clang.

My impression is that during the build, testing for assembler features at a certain point finds clang and runs tests on that.

Those tests indicate certain i386 text relocation features are supported by the assembler, so gcc uses them.

But darwin's i386 linker doesn't know what to do with them, ergo the errors.

So in the portfile, it's easy enough to place this:

configure.args-replace --with-as=${prefix}/bin/as --with-as=/usr/bin/as

but now we just have to figure out when that is needed. All i386 builds? Just go for darwin < 11 say?

[rmottola (Riccardo)]

Any news on this? I was giving an update to 10.5/i386 and stumbled in this again

I could try your fix in the portfile (libgcc or gcc7 itself?) to prove if it is correct

[kencu (Ken)]

the issue is it will currently build for me only with the "gas" original assembler.

our cctools modifications make as call clang if a reasonably new clang exists, and this fails.

If we force /usr/bin/as then that is baked in forever, which is not good.

we don't have a way to force our as to be "gas".

Only thing that works properly is to deactivate all clangs prior to building gcc7/libgcc7, and this is a bit awkward...