stage0 -> stage1 bootstrap currently broken on void and arch

[rofl0r]

since 7620293 , when we started building stage3 gcc with C++ support, so we can build gcc630 during stage1, instead of building gcc474 first as an intermediate step.
the issue is caused by either the specific binutils version (2.27) used by these 2 distros, or by defaulting to PIE. the effect is that the libstdc++.a created during gcc3 build is broken.
so compiling any C++ code with the stage0 compiler fails.
gcc630 will fail during the build with the message

configure: error: cannot compute sizeof (long long)

config.log reveals more details:

configure:6084: g++ -o conftest -g0    -static conftest.cpp  >&5
/bin/ld: eh_personality.o: access beyond end of merged section (1928)
bin/ld: /opt/gcc3/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.6/../../../libstdc++.a(eh_personality.o)(.debug_info+0x6b4): reloc against `.debug_str': error 2
/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

build log of gcc3 is available here: http://true.stallman.faith/PJKYHn.txt

possible solutions:

we could trie to add -Wl,-no-pie to LDFLAGS or LDFLAGS_FOR_TARGET
https://github.com/ldc-developers/ldc/issues/1618
Ubuntu 16.10 linker failures due to PIE by default (relocation R_X86_64_32S … can not be used) · Issue #1618 · ldc-developers/ldc · GitHub
<quote>Btw, I can confirm that when compiling with -relocation-model=pic all issues are gone.</quote>
it might also work by just add -fPIC to CFLAGS_FOR_TARGET

as a temporary workaround until it is fixed, it should be sufficient to just build gcc474 when stage1 fails, and then continue building stage1. gcc474 will then be used to compile gcc630, which should work.

Test 1:
pkg/gcc3:

   CFLAGS="-DSTDC_HEADERS -Werror-implicit-function-declaration" \
-  LDFLAGS="-static" \
+  LDFLAGS="-static -Wl,-no-pie" \
   LDFLAGS_FOR_TARGET="-static $ubuntulibdir" \

build_gcc3.log:

checking whether the C compiler (gcc -DSTDC_HEADERS -Werror-implicit-function-declaration -static -Wl,-no-pie) works... b.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.

/src/build/gcc3/gcc-3.4.6/libiberty/config.log: http://true.stallman.faith/kwpwha.txt

This already fails when trying to build stage0.

Test 2:
pkg/gcc3:

   LDFLAGS="-static" \
-  LDFLAGS_FOR_TARGET="-static $ubuntulibdir" \
+  LDFLAGS_FOR_TARGET="-static -Wl,-no-pie $ubuntulibdir" \
   -j$MAKE_THREADS

Fails also at stage0, but at a later point.
/src/build/gcc3/gcc-3.4.6/x86_64-unknown-linux-gnu/libstdc++-v3/config.log: http://true.stallman.faith/sbuzsX.txt

Test 3:

   CFLAGS="-DSTDC_HEADERS -Werror-implicit-function-declaration" \
+  CFLAGS_FOR_TARGET="-fPIC" \
   LDFLAGS="-static" \

Original error with gcc630 failing to be built from the stage0 enviroment
/src/build/gcc630/gcc-6.3.0/host-x86_64-unknown-linux-musl/gcc/config.log: http://true.stallman.faith/PcqNTD.txt

This change doesn't seem to produce different results from the current brokenness.

[rofl0r]

this issue might be caused by a new relocation type R_X86_64_REX_GOTPCRELX which was added to binutils around 2.25 with no possibility to opt out.
https://sourceware.org/ml/binutils/2015-10/msg00186.html
it might be possible to backport this patch (or at least the part of it that enables recognition of this reloc type, but not the part that emits it) so our binutils version (we stick to it since it's the only one working bugfree on all supported archs) might be able to deal with it properly.

56ceb5b5405af23eddd12e12d8ba849010120324 and 02a866936de7e63ad4962ccba56c8cd05c231275 are the commit hashes in binutils git repo.

[Francesco149]

we tried to backport the patches for that relocation a couple weeks ago, but it looked too complicated for me as the code was very different