On Tue, 24 Jun 2008, John E. Malmberg wrote:
> Andy Dougherty wrote:
> > To the best of my recollection, here's how it's supposed to look for header
> > files:
> >
> > 1. Configure guesses a location $usrinc for header files. Usually,
> > this is just /usr/include. What did Configure guess for $usrinc
> > in your case? (I think we used to prompt for this, but don't any
> > more.) Setting -Dusrinc='none' from the Configure command line (or
> > from a hints file) should disable this file checking.
>
> The VMS standard header files are not in a directory, they are in a text
> library file that compiler knows how to find.
That's fine. It's probably a harmless failure.
Still, setting usrinc='none' will bypass this test entirely, since we
know in advance it's never going to succeed anyway.
> > 2. For each header file $wanted, Configure looks to see if the file
> > $usrinc/$wanted exists. a. If it does, Configure says the header
> > file is found.
> > b. If it does not, then Configure tries locating the header file
> > with the C preprocessor. Essentially, Configure does something
> > like:
> > echo "#include <$wanted>" | $cc -E - | grep $wanted
> > to see if the file is found.
>
> I just tested that code, it fails on VMS. The CC wrapper does not support
> piping the output that way. I will have to add that to the GNV todo list.
>
> I have not figured out where it put the output of the CC -E from the standard
> input, so that is another mystery.
We might get by with using a cppstdin wrapper. For compilers that don't
take input from the standard input, there's a little shell script that
copies stdin to a file and then runs cc on it. For AIX's cc, we use the
-M flag, since the -E flag doesn't help. It would be relatively easy to
add in another special case for VMS. That might be sufficient.
> > > IMHO: If the configure is looking for ANSI/ISO library and compiler
> > > behavior,
> > > it should first test for the routine using the standard headers as the
> > > program does, and only fall back to the other tests if needed.
> >
> > I'm afraid I don't know exactly what you mean by "test for the routine using
> > the standard headers".
>
> 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 think fixing the Configure tests is probably a better plan than adding
> > additional wrappers and workarounds to the VMS compilation scripts.
>
> Sounds good to me.
--
Andy Dougherty [EMAIL PROTECTED]
