Re: branch-1_4 - platform recognition macro

[Andreas Büning]

Eric Blake wrote:
> According to Eric Blake on 6/30/2006 9:05 AM:

> And here's my proposal for the sysval issue.  I went ahead and committed
> it, since I validated that it improves the situation for mingw (at least,
> for a cross-compilation with cygwin build and mingw host).  Andreas, could
> you give some feedback on how 'make check' fares on OS/2 using the latest
> CVS on branch-1_4?

I've just got the latest CVS and installed autoconf 2.60. When I tried to
build m4 I encountered the following error:

$ autoreconf -f -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: g:/usr/autoconf2/bin/autoconf --force
configure.ac:35: error: possibly undefined macro: M4_EARLY
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:53: error: possibly undefined macro: M4_INIT
autoreconf: failed to run g:/usr/autoconf2/bin/autoconf: No such file or 
directory

And I have no idea where to find M4_EARLY and M4_INIT.


I've also just had a look at that thread about system() on the bug-gnulib 
mailing
list. I'm sorry if there's still something unclear to you.

On OS/2 there is a sys/wait.h file which defines
#define WEXITSTATUS(st) ((st) >> 8)

pclose() returns the exit status in the high byte and information about
signals in the low byte. system() returns the exit status in the low
byte and no information about signals. system() may or may not call
a sh-compatible shell depending on some environment variable.


> Also, in my testing, I noticed that mingw had issues with line endings.
> I'm toying with a patch that would force binary processing on all files if
> O_BINARY is defined, rather than text processing, to guarantee line
> endings.  POSIX does say that compliant apps only use m4 on text files,
> and I'm not quite sure how things will behave in binary mode.  On the
> other hand, the autoconf testsuite behaves quite dismally on a cygwin text
> mount, and a binary mode m4 would probably help matters there, and
> autoconf does tend to be the primary user of m4.  Does anyone else have an
> opinion on this matter?

I'm not sure whether I understand this correctly. If you open all files
with O_BINARY on a system that uses \r\n for text files then you can't
read "real" text files correctly on that system because of that trailing \r.
At the moment all files that are created by running aclocal/automake/autoconf
are created as text files (AFAIK), i.e. aclocal.m4, configure, config.h.in,
Makefile.in, etc.

If you read a file in text mode on OS/2, "\r\n" as well as a single "\n"
is treated as line feed (so there's no problem). If you write a file in
text mode, a line feed is written to disk as "\r\n".

Hope that helps.


Andreas