This is the mail archive of the
mailing list for the GCC project.
5.1.0 / 5.1.1 mingw64 bootstrap LTO failure questions
- From: Matt Breedlove <breedlove dot matt at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 11 May 2015 04:33:54 -0400
- Subject: 5.1.0 / 5.1.1 mingw64 bootstrap LTO failure questions
- Authentication-results: sourceware.org; auth=none
I've posted an update to PR 66014 regarding mingw64 slim LTO bootstrap
errors I had been getting I was hoping to get some comments on.
Though this resolves the problem for me, I'm wondering what other
potential issues similar to it may spring up and was hoping to get
In addition, there is another related failure when doing bootstrap-lto
or bootstrap-lto-noplugin (slim or fat) in mingw64 relating to
sys_siglist. mingw64 (as far as I know) does not have an
implementation for it. The issue is as follows:
1. stage1 completes bootstrapping. strsignal and sys_siglist are
undetected resulting in HAVE_STRSIGNAL and HAVE_SYS_SIGLIST.
2. stage2 (or stagefeedback) detects strsignal but not sys_siglist
leaving HAVE_SYS_SIGLIST defined. This causes libiberty to define
strsignal but skips sys_siglist during the build leaving an undefined
reference to sys_siglist.
3. Build fails when attempting to link against the new LTO
libiberty.a(strsignal.o) when building gcc-nm, gcc-ar, etc.
Non-LTO builds suffer neither problem and fat bootstraps only suffer
from the issue above which I have worked around by passing in
"libiberty_cv_var_sys_siglist=no" during configuration. Combined with
building libiberty with "-fno-builtin-stpcpy" (PR 66014), I have
gotten all builds to finally succeed. I could use some guidance on
where to go from here, however.