On Thu, 3 Sep 2015, James Greenhalgh wrote: > On Sun, Aug 30, 2015 at 02:46:26PM +0100, Hans-Peter Nilsson wrote: > > (Pruned the CC list a bit as lists are included anyway) > > > > On Fri, 28 Aug 2015, James Greenhalgh wrote: > > > Give me a shout if you see issues in your build systems. > > > > Since you asked: I saw a build failure for cris-elf matching the > > missing-kill-declaration issue, and I don't like much having to > > take manual steps force a new newlib version. It isn't being > > automatically updated because there are regressions in my gcc > > test-suite results. I guess autodetecting the kill-declaration > > issue in libgfortran is unnecessary complicated, in presence of > > a fixed newlib trunk. All in all, I appreciate you don't force > > a new newlib on release branches. > > Hi, > > I could postpone the pain until after the release of GCC 6, by that > point the newlib change will have a little longer to make it in to > people's trees. On the other hand, this seems like the best way to fix > the issue, and we are probably as well to do it now while we are still > sitting in stage 1.
I do agree; the fault was with newlib for not declaring a standard function that could actually be linked. (It did cause a linker *warning* for the stub function, but libtool didn't care.) > I don't want to cause you too much inconvenience, so if you'd like, I > can revert the more comprehensive patch from trunk for now. I would be > very keen to push it again, either late in GCC 6 development, or soon > after the opening of GCC 7. > > Otherwise, if you're happy enough with the fix staying in place, I'll > just leave it. ...that's why I said "All in all, I appreciate you don't force a new newlib on release branches". Maybe I wasn't clear: you didn't; trunk is not a release branch. Just wanted to cast a vote for that decision to remain as-is. > Sorry to have caused you any issues. No worries. If you hadn't asked to give a shout I'd have remained silent - unless I'd have found other issues. :] brgds, H-P
