|
From: | Martin Koeppe |
Subject: | Re: m4-1.4.7: inconsistency in src/m4.h |
Date: | Sun, 15 Oct 2006 03:33:19 +0200 (CEST) |
Hi Eric, On Fri, 13 Oct 2006, Eric Blake wrote:
OK, you are right that POSIX states that <unistd.h> must define _POSIX_VERSION. And non-POSIX platforms, such as Mingw, are in their best interest to advertise that they are not POSIX compliant by having <unistd.h> leave this undefined. My question is whether having m4 provide the builtin __unix__ is even the right thing for Interix. It's a shame that there are so many viable porting targets for Windows. Mingw, for example, implements system(2) by calling Windows cmd.exe instead of /bin/sh, therefore, I made sure that when M4 is compiled for mingw, it provides the builtin __windows__ instead of __unix__. On the other hand, cygwin intentionally strives for Linux compatibility, and having m4 provide the builtin __unix__ is absolutely the right thing to do. Does Interix provide a /bin/sh that is good enough for system(2), and therefore m4's syscmd builtin, to really behave like a true Unix system? Perhaps it would be better if Interix stuck with __windows__? But since Interix does define _POSIX_VERSION in <unistd.h>, it is worth a shot to let it behave like a unix implementation.
I now see your point. But yes, if for cygwin it is absolutely ok to have __unix__, then for interix it's double absolutely ok to have __unix__ :-). interix, which should be seen as just another unix, is much more POSIX conformant than cygwin as far as the kernel is concerned. You have a case sensitive file system, chroot() and SETUID bits for example. The userland, well ..., that's why I build m4 for it, to get it better :-)
The problem was on src/builtin.c. The very first #include is "m4.h", and there the only #include before the test is "config.h", so no chance for <unistd.h> I think. On other platforms the compiler may #define unix or such itself, so the test succeeds. Indeed if I would use the MS compiler, this would be the case according to docs, but with gcc, it apparently isn't.gcc has a set of pre-defined macros according to the platform it is targeting. The fact that "unix" is not one of them on Interix is an interesting observation; especially since on Cygwin, gcc DOES define "unix" by default.
Yes, this may be a fault on my side, but I didn't yet have a close look.
By the way, M4 can include <unistd.h> blindly, thanks to gnulib portability code (and in fact, already does so, via "unistd--.h"). There is no need to check for HAVE_UNISTD_H, only to rearrange the gnulib header inclusion to occur prior to the platform macro detection section.
This one I don't yet understand. Looking at "unistd--.h" shows that <unistd.h> is also included unconditioned. Maybe the test should be made here? I couldn't find any file named "unistd.h" in m4's source which could be included instead, if the system doesn't have one. So what will happen if you "delete" your system's <unistd.h> before building m4?
And if <unistd.h> is absolutely needed, then configure should stop when not finding it, saying that platforms without it aren't supported, shouldn't it? At least as it checks for it...
Here's what I'm installing. Let me know if you would be willing to try a snapshot tarball on Interix before I release 1.4.8 in the next few weeks.
Yes, sure I can / am willing to do that. Martin
[Prev in Thread] | Current Thread | [Next in Thread] |