Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stage0 -> stage1 bootstrap currently broken on void and arch #505

Open
rofl0r opened this issue Feb 18, 2017 · 5 comments
Open

stage0 -> stage1 bootstrap currently broken on void and arch #505

rofl0r opened this issue Feb 18, 2017 · 5 comments

Comments

@rofl0r
Copy link
Member

rofl0r commented Feb 18, 2017

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.

@ghost
Copy link

ghost commented Feb 19, 2017

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.

@ghost
Copy link

ghost commented Feb 19, 2017

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

@ghost
Copy link

ghost commented Feb 19, 2017

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
Copy link
Member Author

rofl0r commented Aug 17, 2017

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants