[libgcc8] compile failure on i386 on 10.6 Snow

[Ken Cunningham]

> /macports/bin/clang++-mp-5.0 -arch i386 -std=gnu++98   -g  -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -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/macports/lib
> -Wl,-headerpad_max_install_names -no-pie -o build/gengenrtl \
> 	    build/gengenrtl.o build/errors.o
> ../build-i386-apple-darwin10/libiberty/libiberty.a
> clang: warning: argument unused during compilation: '-nopie'
> [-Wunused-command-line-argument]
> ld: illegal text-relocation to '___stdoutp' in /usr/lib/libSystem.dylib
> from '_main' in build/gengenrtl.o for architecture i386
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[3]: *** [build/gengenrtl] Error 1

I notice when you are building libgcc8, the gcc build tools (in this case gengenrtl) are being built 32bit, whereas when I build libgcc8 + universal on my 64bit-capable system, the gcc build tools are built as 64bit only:

/opt/local/bin/clang++-mp-5.0 -arch x86_64 -std=gnu++98   -g  -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -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/gengenrtl \
	    build/gengenrtl.o build/errors.o ../build-x86_64-apple-darwin10/libiberty/libiberty.a
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]


As you are having a rather typical 32bit error, this is likely relevant, and  a good hint as to what the problem is I think.

I have not tried building 32bit-only libgcc8 on a 32bit only 10.6.8 system using clang-5.0, and although I can force this system to build 32bit only, it tries to start pulling in a whole lot of dependencies as 32bit only and I'm not prepared to bomb this system like that just now.

In the end, we probably have to get this onto the LDFLAGS:

-read_only_relocs suppress


gcc builds are more complicated than most, but the ways I would usually approach doing that would be to add one of these in the Portfile:

configure.ldflags-append -read_only_relocs suppress

or

configure.cxxflags-append -Wl,-read_only_relocs,suppress


I have a 32bit only VM somewhere that is a bit rusty right now, but over time, I should be able to get it moving again.

It still could have something to do with building with clang-5.0 ; it is entirely possible that gcc-4.2, which probably built the 32bit-only libgcc8 up until now on 10.6.8 for everyone <http://packages.macports.org/libgcc8/libgcc8-8.3.0_5.darwin_10.i386.tbz2>, automatically added the proper flags for linking, for example, but clang does not.

That's another thing you could do, is force it to build with gcc-4.2 and see if that works. gcc8 does not link against libc++ so you will not be breaking anything to do that.

Best,

Ken