Daniel Jacobowitz wrote:
> On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote:
>> Daniel Jacobowitz wrote:
>>> Paolo's updates added a check for runetype.h
>>> in order to make Mac OS/X's <wchar.h> work properly. Perhaps gnulib's
>>> substitute wchar.h ought to handle that?
>> For which version of Mac OS X was this? MacOS X 10.3 has a working <wchar.h>.
>> MacOS X 10.2 has no wchar.h at all. When gnulib introduced the 'wchar'
>> module,
>> we effectively dropped support for this platform (on 2007-01-12 and
>> 2007-01-16).
>
> I don't know the answer to that, so I'll let Paolo answer.
>
> My current snprintfv work has fallbacks for a missing wchar.h - this
> code is just for the "present but broken" case. I'm not sure what
> portability goals I should adhere to for this project.
Reports from my "autogen clients" say that it will not build correctly
on some variation of OS/X without testing for and pre-including
this "runetype.h" thing, despite having a "wchar.h" header.
I have not, myself, gotten around to figuring out how to use
gnulib and expunge my project of compatibility cruft, but I
would sure hope that fixing this winds up as easy as adding
"wchar-h.m4" module and in my code:
#include "config.h"
#include WCHAR_H_FILE
and, perhaps, on whichever OS/X it is that needs the "runetype.h"
file, you'd have this:
cat > config-wchar.h <<- _EOF_
#include <runetype.h>
#include <wchar.h>
_EOF_
cat >> config.h <<_EOF_
#define WCHAR_H_FILE "config-wchar.h"
_EOF_
The bottom line is that there really is some flavor of OS/X that
has this pre-include of "runetype.h" requirement out there somewhere.
The proper place to accommodate it is in the wchar module.
Thank you all for this project! (I'll repeat the thanks again
when I actually find time to incorporate it!)
Cheers - Bruce
