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.
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.
> And some times if it does not find the header
> file, it skips the test for the routines.
Yes. In some cases, it appeared to be "obvious" that, for example,
if you didn't have gdbm.h, you were unlikely to have gdbm_open().
In other cases (vague mememory suggests something related to sockets)
if you didn't have the relevant header available, then you probably
didn't have the whole related package available.
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".
> > > : 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.
I think fixing the Configure tests is probably a better plan than adding
additional wrappers and workarounds to the VMS compilation scripts.
--
Andy Dougherty [EMAIL PROTECTED]
