autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-platform availability of header files


From: Zack Weinberg
Subject: Re: Cross-platform availability of header files
Date: Sat, 16 Mar 2013 09:15:26 -0400

On Sat, Mar 16, 2013 at 1:06 AM, Ralf Corsepius
<address@hidden> wrote:
> On 03/15/2013 09:13 PM, Zack Weinberg wrote:
>> On 2013-03-15 8:57 AM, Ralf Corsepius wrote:
>>>
>>> aio.h and sys/mman.h are not available everywhere
>>
>>
>> aio.h certainly, but are you aware of a *specific Unix-like system*
>> which is in current use and does not provide <sys/mman.h>?
>
> Unix-like! Not all OSes are Unix-like.

The whole point of this project is to pin down the remaining variation
among OSes that *are* Unix-like, because IME that is the case where
AC_CHECK_HEADERS is most useful.

> Most prominent one without mman.h is mingw. Others, I am aware about are
> certain newlib based toolchains.

This may be skewed by the software I've been working on lately (very
network-intensive) but portability to anything Windows-based seems
best accomplished by conditioning stuff on #ifdef _WIN32.  In
particular, I don't see any real value in using AC_CHECK_HEADERS to
figure out whether you need sys/socket.h and friends or winsock2.h,
because there's going to be variation scattered through the code as
well, and _WIN32 makes a reliable master switch for all of it.
Similarly, _WIN32 will tell you whether to use sys/mman.h and mmap or
windows.h and MapViewOfFile.

That's why I wrote the original blog post the way I did: my logic is
that you can use _WIN32 to figure out if you've got Windows, and only
bother to do autoconf probes for things that are variable among
platforms that *aren't* Windows.  I'd speculate that the same is true
for other decidedly non-POSIX environments; VMS, z/OS, and VxWorks
come to mind, altho I have no idea how relevant any of them still are.

I don't know which box to put newlib in, though.  I know it's used in
embedded environments, but I don't know what the underlying OS(es?)
are like.

>> I'd believe there
>> might be embedded mostly-POSIX-compliant environments still that don't
>> do virtual memory, but I've never seen one.
>
> Correct - RTEMS is one of these. We have a rudimentary implementation of
> aio.h since 2010 and don't have mmap.h at all.

If you send me header lists for RTEMS and any other non-Windows-based
embedded systems you think should be considered, I'll be happy to
update my tables.  As I said elsethread, trailing-edge versions are
actually better than brand new ones for this analysis.

zw



reply via email to

[Prev in Thread] Current Thread [Next in Thread]