Re: Why require SLOW_BUT_NO_HACKS for stubs?

[John Spencer]

On 06/25/2012 08:31 AM, Paul Eggert wrote:
> On 06/24/2012 03:42 PM, John Spencer wrote:
> > anything is better than a failed build.
> Isn't this discussion moot now, with respect to musl?
> That is, I thought the problem with musl and gnulib
> is fixed, so we don't have a failed build now.

we still will have failed builds until all software using gnulib will 
update their in-tree copies and release new versions.
this can take a long time. an optimistic estimate is ~2 years.
and when you don't you want to use the latest version for whatever 
reason, you will still have to fight this problem.
for example i prefer using gcc 3.4.6 or 4.2.4 on embedded machines as it 
is much more lightweight (however in that specific case it's fighting 
against the broken prototypes in libiberty).

> If this discussion is about what to do with some other
> new standard C library that gnulib isn't ported to yet,
> let's wait until that happens before worrying about it.

i'm thinking about the future, when i (or others) will run into the same 
error when i use nuttx, aros, RTOS, QNX, or something else that comes my 
way. unless a portable fallback is *activated* by default, any new 
system will have to fight against gnulib with its arrogant attitude.
> Perhaps by then the necessary primitives will be standardized
> so the problem won't come up then either.
the problem wouldn't come up in the first place if you activated 
portable fallbacks for weirdo code like fseterr.
people were happy and would think gnulib is a fine thing, because it'd 
simply work as intended.