On Mon, Aug 18, 2003 at 06:40:12AM -0700, Jeffrey Isherwood wrote:
> I verify'd the GCC and CPP installs, and apparently there is an error of some
> sort during the config that is causing the ./configure to not use the gcc -E
> but I don't know enough about compiling to understand the errors.

I'm sure you can figure it out.  It's something we can't do because we 
can't reproduce your problem and we don't have access to your system, 
and even if we did we couldn't fix it on your system.  It just takes a 
bit of time trying to understand what commands the configure script is 
running and which one is failing, and why.

The swish-e list strips attachments so you config.log file didn't make 
it to the list.  That might have offered better clues.  You should look 
carefully at that output again.

Here's what I'd do if config.log doesn't make it clear.

Open up configure in an editor and throw in some statements so you
can see what's happening.

For example, search for "checking how to run the" and start from there. 
You can see how the configure script is setting a few variables, then
it's writing out a small sample C program to the file conftest.$ac_ext. 
That C program is then compiled with the -E command (at least on my
system).

For example, after these lines:

  #endif
                     Syntax error
  _ACEOF

I add these lines:

  ls -l conftest.$ac_ext
  cat conftest.$ac_ext
  eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\""
  exit;

Now configure outputs:

-rw-r--r--    1 moseley  moseley       358 Aug 18 07:55 conftest.c
#line 3711 "configure"
/* confdefs.h.  */

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "swish-e"
#define VERSION "2.4.0-pr1"
/* end confdefs.h.  */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif
                     Syntax error
configure:3729: gcc -E  conftest.c

The configure script then checks for errors from that compilation -- and 
if there's an error sets the ac_cpp_err flag to "yes", or if no errors 
but there's an error output file sets $ac_c_preproc_warn_flag.

So after that fi { }; then fi (kind of long statement) you can add 
something like:

  echo error = [${ac_cpp_err}]

If it's not getting an error there then go onto the next section of the 
configure script and do the same thing.  The next section tries to 
include a non-existent header file and check that it can detect errors.

When you see why $ac_preproc_ok is not being set you will find out what
operation is failing.

My experience has been that once you do all that and go back to the 
config.log file that the answer was already available in the config.log.

-- 
Bill Moseley
moseley@hank.org