Re: branch-1_4 - platform recognition macro

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Andreas Büning on 6/30/2006 2:36 PM:
> 
> 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

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.

> 
> 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.

Oh yuck.  Does OS/2 define an easy preprocessor macro for determining the
host system (for example, cygwin has __CYGWIN__, mingw has __MINGW32__,
etc.)?  As for how we would test for this bug during configure, how does
this test program behave for you?  (Since it is a run test, I will
probably just assume on cross-compiles that the bug is not present, since
cross-compiling to OS/2 is pretty rare).

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

int main()
{
  int i1, i2;
  FILE *f;
  i1 = system("exit 2");
  if (i1 == -1)
    {
      printf("system failed with %d\n", errno);
      return 1;
    }
  f = popen("exit 2", "r");
  if (!f)
    {
      printf("popen failed with %d\n", errno);
      return 1;
    }
  i2 = pclose(f);
  if (i2 == -1)
    {
      printf("pclose failed with %d\n", errno);
      return 1;
    }
  if (i1 != i2)
    {
      printf("system and pclose disagree\n");
      return 2;
    }
  printf("test passed\n");
  return 0;
}


What I will probably do is that if the bug is detected, I will implement
syscmd in terms of popen()/pclose(); using the trick of undivert rather
than sinclude for copying the output from the pipe to stdout.  But I will
be relying on you for testing it, since I don't have access to a platform
with the bug.

> 
> 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.

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.

> 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".

Yes, those semantics match how mingw and cygwin text modes behave, so I
have a good test platform for this.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEpniy84KuGfSFAYARAq+RAKCI2g+Z03daj5AI+xTPvNmr5kizUACggkpB
P3g/IY7nPNR0VXroXZouZx8=
=Lh1O
-----END PGP SIGNATURE-----