DragonFly users List (threaded) for 2010-02
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: pkgsrc bash-4.1 won't build
Max Herrgård wrote:
> Den 2010-02-08 09:00:02 skrev Steve O'Hara-Smith <steve@sohara.org>:
>> Hi,
>>
>> I've just done a pkgsrc update and fired off a build of my packages
>> only to find that bash fails to build because of this bit of code:
>>
>> # if defined __sferror || defined __DragonFly__ /* FreeBSD, NetBSD,
>> # OpenBSD, Dra
>> gonFly, MacOS X, Cygwin */
>> if (result == 0)
>> /* Correct the invariants that fpurge broke.
>> <stdio.h> on BSD systems says:
>> "The following always hold: if _flags & __SRD, _w is 0."
>> If this invariant is not fulfilled and the stream is read-write
>> but
>> currently writing, subsequent putc or fputc calls will write
>> directly
>> into the buffer, although they shouldn't be allowed to. */
>> if ((fp->_flags & __SRD) != 0)
>> fp->_w = 0;
>> # endif
>>
>> I can't get it to compile because of course FILE is unavailable,
>> but is the statement that DragonFly fpurge breaks an important invariant
>> correct ? If so fixing it in fpurge is of course trivial and I think
>> desirable - if not then I think bash should not be fixing it outside
>> libc.
The statement is correct. One could fix fpurge() (though I bet it breaks
other assumptions as well) or could cast the FILE* to __FILE_public*
and use it's _flags and _w fields.
> hi. rumko filed a pr for this:
> http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=42666. is it the
> same issue?
Yes. Like I exlained above, I don't think removing the code for
DragonFly is the correct solution. Unless someone takes the time to
audit fpurge(), I suppose using __FILE_public is the safest "fix" since
it brings us back to how things were.
HTH,
Aggelos
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]