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 looks like it is using the test programs for testing the existence of
routines, not the header files. And some times if it does not find the
header file, it skips the test for the routines.
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.
The way that the gnu configure is now, the tests may be producing
incorrect results, in many cases mis-diagnosing that a routine is
missing or broken, and may be substituting less efficient code to
compensate. Unless you are carefully auditing the results of configure
for a platform, this unneeded substitution may not be noticed.
This will be most common on platforms that use a single shared image for
the supplied libraries, and provide backwards, binary and bug
compatibility for prior versions.
: 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.
You need to get the equivalent of CC/PREFIX=ALL and possibly other
options in there for the compiler. Something like:
That does affect the problem. In the above example, for configure to
get the expected results, the decc$_posix_exit() needs to be called for
exit(). With out pulling in the standard header file, you get decc$exit.
decc$exit() translates exit(0) and exit(1) to VMS status of 1 for
success. Configure scripts often use exit(1) to indicate a failure.
And the CC wrapper under bash already sets almost all the compiler flags
as best suited for building UNIX source.
Also the interlocked I/O routines are only visible if a standard header
is used, and a #define is also set. I can rig the CC wrapper to do the
#define, but not add in the header in a way that the typical configure
script will accept.
The header files also determine which TCPIP socket routines are visible.
On VMS, if you compile a test program with out using the header files,
you get the VAX/VMS 5.5-2 or earlier behavior of the routine. If it was
later determined that was an incorrect behavior, in many cases a new
entry point was added so that programs expecting the incorrect behavior
would continue to function. The header files on VMS use internal and
user #defines to determine which routine to use at compile time.
$ Configure -ccflags="-I. -std01 -ieee" might be a place to start. Do
$ cc -h
within bash to see the options for GNV's wrapper around the native compiler.
I was the last person to work on that wrapper as far as I know, and I
did a lot of work to fix the syntax handling. It still needs more work,
as it can not handle quoted strings with spaces in them.
-John
[EMAIL PROTECTED]
Personal Opinion Only
