Re: config-list.mk and obsoleted configurations

[Trevor Saunders <tbsaunde@tbsaunde.org>]

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 <law@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 <law@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