Description of problem: During the stage2 bootstrap we experience glibc segfaults when chrooting into the minimal environment. The issue only happens for some combinations of builder and target architectures. Since it's difficult to collect sufficient debug data, we offer an access to the build environment where we're able to reproduce the issue. I tried to do a diff of the nm output for a working and non-working libc.so.* and both contain the same symbols. However they differ in addresses and that probably means the generated code differs. Version-Release number of selected component (if applicable): glibc-2.20-8.fc21 gcc-4.9.2-6.fc21 binutils-2.24-32.fc21 How reproducible: always
Arch? I think you saw this on aarch64?
It applies to multiple architectures. aarch64 is just one of them. Right know I'm sure it's reproducible with all B=T rootfs except x86_64.
Adding DJ as we expect he'll be lending a hand on getting the bootstrapping process going.
Turns out the root cause of this problem is this line in stage1's glibc recipe: echo libc_cv_ctors_header=yes >> config.cache Commenting out or removing that line should fix it.
Thanks guys. Gonna try.
Seems to work for all previously failing combinations. I couldn't test s390 due to an outage, but I believe it's ok too. Thanks a lot for the fix.