Re: branch-1_4 - platform recognition macro

[Andreas Büning]

Eric Blake wrote:

> According to Andreas Büning on 6/30/2006 2:36 PM:

> > configure.ac:35: error: possibly undefined macro: M4_EARLY
> 
> You need to have a recent CVS checkout of gnulib available, and rerun m4's
> bootstrap with gnulib-tool either on your path or located in the
> environment variable GNULIB_TOOL.  (Hmm, I probably ought to add a HACKING
> document for CVS only that better describes this).  M4_EARLY is built by
> gnulib-tool, called during bootstrap.

Done. Then the linker complained about 'gl_va_copy' being an unresolved
external. Reason is that va_copy is defined to gl_va_copy in config.h.
gl_va_copy is supposed to be defined in m4/stdarg.m4. I added gl_STDARG_H
manually to configure.ac but this didn't help because the gl_STDARG_H
macro in m4/stdarg.m4 uses the AH_VERBATIM macro with an invalid syntax which
results in a noop. 


> Oh yuck.  Does OS/2 define an easy preprocessor macro for determining the
> host system (for example, cygwin has __CYGWIN__, mingw has __MINGW32__,
> etc.)?

__EMX__


> As for how we would test for this bug during configure, how does
> this test program behave for you? 

I added some printfs to the test:

system returned: 2
pclose returned: 512
system and pclose disagree


> The question is whether reading \r in a preprocessor, and immediately
> spitting it back out in binary mode, still leaves a consistent output file
> with \r\n endings.  My gut feeling (although I have not yet tested it on
> cygwin text mounts) is that since none of the builtins break their output
> across lines, that all line breaks in the output come from line breaks in
> the input, so reading in binary mode should still work.

This could work on DOS/Win*/OS/2. However, I had vague memories that
traditional MacOS uses single \r as linefeed (see, e.g,
http://kb.iu.edu/data/agiz.html). I don't know how relevant this is
nowadays.


Andreas