DragonFly BSD
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


From: "Steve O'Hara-Smith" <steve@xxxxxxxxxx>
Date: Mon, 8 Feb 2010 17:44:39 +0000

On Mon, 08 Feb 2010 15:10:21 +0200
Aggelos Economopoulos <aoiko@cc.ece.ntua.gr> wrote:

> 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.

	So this patch (which works for me):

--- fpurge.c.orig	2010-02-08 17:31:18 +0000
+++ fpurge.c	2010-02-08 17:32:31 +0000
@@ -61,8 +61,13 @@
        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 defined __DragonFly__
+    if ((((struct __FILE_public *) fp)->_flags & __SRD) != 0)
+      ((struct __FILE_public *) fp)->_w = 0;
+#else
     if ((fp->_flags & __SRD) != 0)
       fp->_w = 0;
+#endif
 # endif
   return result;


-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]