[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why require SLOW_BUT_NO_HACKS for stubs?
From: |
Isaac Dunham |
Subject: |
Why require SLOW_BUT_NO_HACKS for stubs? |
Date: |
Sat, 9 Jun 2012 23:05:41 -0700 |
Hello,
I'm using musl as a libc, and have run into a number of times that
gnulib stopped build.
By defining SLOW_BUT_NO_HACKS, the software ended up working.
This is the documented behavior, but it doesn't seem like the right one:
if a stub is usable enough to allow using it, why shouldn't it be
available whenever there's no alternative?
Is there any reason not to merge the
#else if SLOW_BUT_NO_HACKS
sections with the
#else
#error
sections, either with #pragma warn instead of #error, or without any
messages?
Isaac Dunham
- Why require SLOW_BUT_NO_HACKS for stubs?,
Isaac Dunham <=
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paul Eggert, 2012/06/10
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Isaac Dunham, 2012/06/11
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paolo Bonzini, 2012/06/12
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, John Spencer, 2012/06/12
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Bruno Haible, 2012/06/17
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paolo Bonzini, 2012/06/23
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Bruno Haible, 2012/06/24
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, John Spencer, 2012/06/24
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paul Eggert, 2012/06/25
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, John Spencer, 2012/06/25