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 _______________________________________________ M4-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-patches
