On Thu, Dec 17, 2015 at 12:53:20PM -0700, Jeff Law wrote: > On 12/17/2015 11:58 AM, Jan-Benedict Glaw wrote: > >On Thu, 2015-12-17 11:39:24 -0700, Jeff Law <l...@redhat.com> wrote: > >>On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote: > >>>On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <l...@redhat.com> wrote: > >>>>On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote: > >>>>>Shall I bisect one of the cases anew, with the "Test value of > >>>>>_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that > >>>>>uncovered it, applied? Starting with some arbitrary old revision? > >>>>Yes. I'd really like to see config-list.mk working again. The > >>>>first step is always building a test the developers can easily work > >>>>with. > >>> > >>>Will do. Have a good starting point? > >>The biggest problem is the breakage around wither USE_C99_WCHAR or delayed > >>folding. I think I counted 30+ targets that were effected. > > > >It's probably delayed folding; seems the USE_C99_WCHAR stuff only > >uncovers it, doesn't it? > > > >>Once that's settled, I suspect anything remaining will be pretty minor. > >> > >>I'd disable interix completely. > > > >Seems to be not hard to fix. Breaks with: > I know, but it's not worth fixing IMHO. Interix has been a dead product for > a long time. We almost got rid of it several years ago, but someone > objected and said they'd maintain it. I asked Trevor to put it back on the > deprecated list a little while ago. > > AFAICT it hasn't been building since 2012. I fixed some of the problems a > few months ago, but just can't really justify anyone's time to figure out > which way to #define this away to preserve prior behaviour and to continue > to keep it working over time.
and killing it will help move towards killing other things you dislike like sdb and dbx. > > > > >>Not sure what to do with avr-rtems at this point. > > > >My buildrobot just fails at the very same USE_C99_WCHAR issue right > >now. Is there something more hidden, later on in the build? > avr-rtems has deeper issues, which ultimately look like the same problem > you're seeing with delayed folding, but aren't the same problem. > > Essentially avr-rtems's definitions of various standard types are all > conditional on flags with a default that is NULL. Those are ultimately > passed to one of the str* functions and GCC throws a warning/failure. hWell, it might be the only target that has warnings because of that, but from a quick look it seems like any target that uses avr-stdint.h or newlib-stdint.h could theoretically have null values for those macros. Without a bit of digging I'm not sure how much of that is real and how much is completely theoretical archs that would have any number of other problems. Trev > > There's no way to fold those down to a constant, (or even to prove the NULL > case couldn't happen IIRC). So even once the current delayed folding issue > gets fixed, avr-rtems will remain broken. > > It's also unclear how long avr-rtems will be around. I get the sense it's > on its last legs -- and given we have both avr and rtems coverage via other > targets, I don't think building avr-rtems is really all that helpful. > > Jeff
