Andy Dougherty wrote:
> John Malmberg wrote:
> > I mean use the system supplied headers that contain the
> > prototype for the routine.
>
> But the existence of a prototype in the system-supplied headers does
> not guarantee the availability of the routine. There are oodles of
> counter examples. But I think I know what you mean -- the
> test for the routine ought to include the appropriate headers.
I maintain the port of various open-source packages to the Stratus VOS
operating system. I have had to resolve similar (tho not identical)
issues here. Our POSIX environment is layered on our C environment,
which in turn is layered on a proprietary OS.
I don't think I'll bore you with the details of how we solve it, because
I don't think our solution is applicable to VMS. (I'll be happy to
explain it offline). But I will say that you are shoveling the tide if
you hope to get the open-source world to teach its configure scripts to
#include the appropriate header file prior to testing for the existence
of a POSIX function. You will find it far easier to tweak your build
environment to have the appropriate set of defaults when building POSIX
code. There are a dozen or more open-source build frameworks and
hundreds of packages.
If you want to change the world, you will have to work with the
maintainers of autoconf to change their standard macros. Assuming that
goes OK, then you will have to wait for every client of autoconf to
adopt the new macros. In my experience, that step literally takes
years. I made a much simpler change, to the config.sub and config.guess
scripts about 5 years ago, and I'm still poking on maintainers to update
their copies to have these changes.
The one point of consistent leverage that you have when you build nearly
all open-source packages is the ability to specify the set of flags that
get passed to the preprocessor, compiler and linker. Some scripts want
to seem all of the flags mushed into CFLAGS. Better scripts allow you
to specify CPPFLAGS, CFLAGS, and LDFLAGS independently.
In my experience, if you can confine your platform-specific magic to
setting up appropriate values for these variables, you will find that
you will have a MUCH easier time of porting open-source packages. Once
in a while, I find it necessary to pre-assign values to various autoconf
config variables, but I try to avoid that unless absolutely necessary.
As a quick hack, you might consider supplying an header that included
all of the standard headers, and then specifying that it be used in all
compilations. For example:
cat >vmslib.h <<EOF
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
[ and so on ]
EOF
declare -x CFLAGS="-D_POSIX_C_SOURCE=200112L -include vmslib.h"
Or, if you have the ability to add some clever pragma to your port of
GCC, you could use this header file to specify an appropriate pragma
("#pragma do_the_right_thing;"), and then have code in GCC to set up an
appropriate default build environment. Or forget the pragma, and just
hack GCC to always build POSIX code.
I like the idea of a new pragma better than vmslib.h, because the brute
force method of including all of the headers almost certainly will
introduce new namespace issues, whereas just getting the right set of
defaults enabled for your build environment is the clean solution. If I
understand your environment, it seems that you want to ensure that you
invoke a certain minimum revision of each function; the revision that is
POSIX-compliant, not a pre-POSIX version.
Hope these comments help you find a workable solution.
Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen
