Eric Blake wrote:
> Paul, any reason include_next.m4 doesn't reuse absolute-header.m4?
Not that I recall.
Hello, all. I've been experimenting in porting a GNU project to Windows
while preserving Unicode capability. Prepending _t everywhere like
Microsoft suggest is hardly an option due to change of code it requires
and subtle problems with it. E.g. consider code:
s = malloc (strlen (a) + strlen (b) +
On 10/11/2013 12:45 PM, Rhys Ulerich wrote:
>
> I pulled gnulib, patched it with the diff modified to use
> 'linux*:bgxlc*', and then ran 'gnulib-tool --update' to try to snarf
> it. Then nothing happened. And I noticed absolute-header.m4 isn't
> populated in my project tree by gnulib-tool. Doe
> Now we just need to modify the .m4
> file to use -C whenever $CC is bgxlc_r.
FWIW, the non-reentrant bgxlc behaves the same way as bgxlc_r with
respect to this float.h issue. Probably worth using 'bgxlc*' for the
patch.
> Does this work for your user?
> I'm a little bit hesitant to key off o
On 10/11/2013 12:11 PM, Rhys Ulerich wrote:
>
>> $ echo '#include ' > foo.c
>> $ bgxlc_r -E foo.c > float.out
>
> This produces a zero-length float.out. My user reports there's no
> float.h file sitting alongside other headers in the usual places.
Makes sense on two fronts - at least with gcc,
