The GNU way of doing things is specific to GNU and, as far as I can
see, GNU has never been concerned with maintaining backwards
compatibility.
Most of the configure scripts I have encountered simply attempt to
compile a short c/c++ program that contains a statement or two but no
include files. If the statement fails, then support must not be
present. To me, this approach explains a lot of the really bad coding
I've seen in some open source projects.
I worked around this by having GNV specify a /first_include switch
that specified a file I had created that set up the necessary
environment (.e.g, define _USE_STD_STAT, _SOCKADDR_LEN, __NEW_STARLET,
etc. then include all of the headers that should have been included by
the configure script's generated programs). This solved the problem
for me except for those configure scripts that include ASM
statements. I should note in passing that I probably haven't used
that many configure scripts.
Mark Berryman
On Jun 18, 2008, at 7:40 AM, 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 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
