Re: hppa2.0-hp-hpux10.20 mixed Fortran and C

[Ralf Wildenhues]

* Steve Edwards wrote on Wed, Aug 23, 2006 at 02:40:19PM CEST:
> On Wed, 2006-08-23 at 14:04 +0200, Ralf Wildenhues wrote:
> > * Steve Edwards wrote on Wed, Aug 23, 2006 at 01:54:56PM CEST:
> > 
> > This looks like there are some manual overrides in the Makefile.am file.
> > Could you show a small example exposing this, or show the respective
> > parts of the Makefile.am?  Especially I don't see at all where the
> > autotools should cause a file like xlf.ul_beeper.errors to be used.
> 
> Sorry about that - you are quite correct there are indeed some manual
> overrides.

Automake has some support for preprocessed Fortran 77.  Could you try
whether that is sufficient for you, and if not, please describe what is
missing (I am trying to whip up Fortran support a bit at the moment...)?
Please see the Automake documentation for details.

What do you need the @EXTRA_FLAGS@ for?

> I should have added those to the first post. First of all, at
> configure time the user can specify EXTRA_FLAGS which are appended to
> the compiler flags (see below). The other change is Fortran specific
> which (dependant upong platform and compiler) attempts to work out a
> method for pre-processing Fortran source. If no flag is know to the
> configure script it uses an automake conditional to generate
> pre-processed Fortran:
> 
> if PPHASH
> .f.o:
>       $(FTNPP) $(FTNPPFLAGS) @DEFINES@ $(AM_CPPFLAGS) `test -f '$<' || echo
> '$(srcdir)/'`$< > $(*F).F && $(F77COMPILE) -c -o $@ $(*F).F
> endif

Besides the fact that I think Automake does not cope well with
conditional overrides of inference rules, I believe you need to override
the rule for `.f.lo' as well, for files handles by libtool.  I think
this is the cause for the error you see (untested).

> If a flag is known it sets FPPFLAGS, but this has to be set for the
> compile stage only and not the link stage - g77 uses -xf77-cpp-input and
> fails if you leave this in the command line at link time as then it
> tries to pre-process the object code.

See above, that should be a non-issue if you use file names ending in
.F, given that Automake does the preprocessing logic correctly then.
Automake will use
  PPF77COMPILE = $(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
          $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)

for compilation.  If that is a problem with colliding *CPPFLAGS for
C/C++ files compiled from the same Makefile.am, you could just compile
them in a different directory as a workaround.

> I may try stripping down the automake/autoconf to an absolute minimum on
> that platform and just try building a library with 2 routines - 1 C and
> 1 Fortran to see if it still occurs. Would that be of any use to you if
> I did that?

It would certainly help.

Cheers,
Ralf