After 93ae1ebaa6df1a0c188614bd0a601ab6e26711c5 (also see bug 14171), gnu/lib-names.h isn't generated anymore, which breaks my build (including from-scratch builds) because /usr/include/gnu/lib-names.h on my system doesn't have a LIBGCC_S_SO entry: ../sysdeps/gnu/unwind-resume.c: In function ‘init’: ../sysdeps/gnu/unwind-resume.c:36: error: ‘LIBGCC_S_SO’ undeclared (first use in this function). Manually doing the following (on x86_64) make gnu/lib-names.h make gnu/lib-names-64.h fixes the issue. This is on a RHEL-6.5-based distro with GCC 4.4.7.
I cannot reproduce that.
(In reply to Andreas Schwab from comment #1) > I cannot reproduce that. On RHEL 6.5? Or which distro/GCC version did you use? I've heard from others that they can't reproduce on Fedora 20 either.
(In reply to Torvald Riegel from comment #2) > (In reply to Andreas Schwab from comment #1) > > I cannot reproduce that. > > On RHEL 6.5? Or which distro/GCC version did you use? > I've heard from others that they can't reproduce on Fedora 20 either. I can't reproduce on F20, but that doesn't mean it isn't a problem. I'd like to know *why* it doesn't build. I would also be curious to know Joseph's opinion since he reworked the rules into Makerules and might have a better understanding of what is wrong with either the environment or our rules.
gnu/lib-names.h (and gnu/lib-names-$(default-abi).h) is in $(before-compile) and so should be generated before any .c files are compiled. Maybe the additions to before-compile need to move further up Makerules before the dependencies on $(before-compile) are added, or something like that?
Fixed by 67c379871ed04c4494f3fb01b012504d6cf63f6e