pkgsrc bash-4.1 won't build

Aggelos Economopoulos aoiko at
Mon Feb 8 05:12:15 PST 2010

Max Herrgård wrote:
> Den 2010-02-08 09:00:02 skrev Steve O'Hara-Smith <steve at>:
>>     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:
> 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.


More information about the Users mailing list