Andy Dougherty wrote:
On Wed, 18 Jun 2008, John E. Malmberg wrote:
Craig A. Berry wrote:
At 11:48 PM -0500 6/16/08, John E. Malmberg wrote:
Most of the tests for the existence of the header files failed. I
am assuming that it was trying to find them in the usual places on a *NIX
system.
It mostly compiles little test programs -- I'm not sure if it does
any actual filesystem hunting at all.
I run configure scripts that run the little test programs all the time, and
they are able to find the standard libraries. They need some help in finding
the stuff like Kereberos, ssh, etc.
It was the configure script reporting file not found, not the compiler.
(It may be hard to tell -- the compiler may have reported the error, but
the configure script may have intercepted that output and be reporting it
instead.)
It looks like it is using the test programs for testing the existence of
routines, not the header files.
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.
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.
Once we fix up the header detection, I'd be interested in learning of
specific cases where Configure's attempts to take such shortcuts lead to
errors.
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.
: exit(0);
:........^
:%CC-I-IMPLICITFUNC, In this statement, the identifier "exit" is
: implicitly declared as a function.
On VMS, if you call a routine with out the system headers, you get
the oldest entry point for that function, and some functions are not
visible unless the header files are used to prototype them.
Even when not on VMS, we shouldn't be producing warnings. Since Configure
predates ANSI C, we historically haven't assumed headers like <stdlib.h>
were available. We now require ANSI C for perl, so going through and
adding #include <stdlib.h> and otherwise modernizing many of Configure's
little test programs would be a fine task for the interested.
The above is not a warning, it is an informational message. In this
case the decc$exit() routine is being called, which is the one that
expects the status code to be a 32 bit packed structure contained in a
longword, not a POSIX exit code.
This decc$exit(0) translates the 0 to be 1, as 1 is the VMS DCL exit
code. Bash will also see this as a 1.
If the stdlib.h header file is included, the GNV environment sets the
option to have the 1 encoded in a reserved VMS value. Bash will decode
that back into 1 and all will be well.
I have back doors built into GNV, where the file 'gnv$try.c_first' will
be effectively pre-pended to the try.c being compiled, and I can put
prototypes or even fake stub routines to make things work, which is what
I have to do with other configure scripts.
The file gnv$<file>.opt is instructions to the VMS equivalent of LD for
linking.
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.
-John
[EMAIL PROTECTED]
Personal Opinion Only
