[ast-developers] Updating ast-open for FreeBSD

[Bob Krzaczek]

I'm working to get ast-open building again on recent FreeBSD (9.1 on
amd64 to be specific). I've been able to work through a few issues so
far (including fixing AT_FDCWD by a small update to
libast/features/standards), but now I could really use some advice.
I'm using {INIT,ast-open}.2014-03-01.tgz presently.

During the early configuration of ast-open, the following error
occurs. Needless to say, this happens repeatedly throughout the build.

conf: probe for WINT_MAX <limits.h> value
conf: probe for WINT_MIN <limits.h> value
In file included from ./ast_wchar.h:99,
from /home/krz/ast2/src/lib/libast/include/ast_std.h:101,
from /home/krz/ast2/src/lib/libast/include/ast.h:34,
from /home/krz/ast2/src/lib/libast/misc/state.c:26:
/usr/include/../include/wchar.h:102: error: conflicting types for '_sfio_FILE'
./ast_stdio.h:80: error: previous declaration of '_sfio_FILE' was here
mamake [lib/libast]: *** exit code 1 making state.o

Additionally, from /usr/include/wchar.h,

100 #ifndef _STDFILE_DECLARED
101 #define _STDFILE_DECLARED
102 typedef struct __sFILE FILE;
103 #endif

Even though the __sFILE structure is only defined in stdio.h, that
header isn't included by /usr/include/wchar.h, either directly or
through other nested includes. Incidentally, those exact same four
lines can be found in /usr/include/stdio.h, directly after the
definition of that structure. So, at least it's consistent, the
FreeBSD headers always leave FILE as a typedef to __sFILE.

The reason this appears in /usr/include/wchar.h is because the wide
character variants of a number of functions are declared later in that
same file.

106 __BEGIN_DECLS
107 wint_t btowc(int);
108 wint_t fgetwc(FILE *);
109 wchar_t *
110 fgetws(wchar_t * __restrict, int, FILE * __restrict);
111 wint_t fputwc(wchar_t, FILE *);
...

So, while I see what's going on in libast (there are CPP definitions
of FILE to the _sfio_s structure (or the _sfio_FILE typedef of the
same) throughout ast.h, ast_std.h, and ast_stdio.h), I'm still just a
bit too unfamiliar with iffe and friends to really know how to proceed
here. Clearly, similar situations have been anticipated in the iffe
scripts (hence all the wrangling over stdio.h and wchar.h), but I'm
unsure how to tune it to handle this case.

Any guidance or hints would be very appreciated.

Cheers,
Bob