This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

5.1.0 / 5.1.1 mingw64 bootstrap LTO failure questions


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
some feedback.

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.

Thanks,
Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]