Re: how to tell autoconf/automake where fortran .mod file lives

[Keith Marshall]

On Sunday 16 March 2008 01:27, Tim Dennis wrote, quoting me:
> >> the macro call:
> >> AC_SEARCH_LIBS(h5open_f,[hdf5_fortran],[],[],[ -L$prefix/lib
> >> -I$prefix/lib])
> >
> > This doesn't look right; that final argument isn't for specifying
> > what LDFLAGS should be, it is to specify *other* libraries which
> > are needed to satisfy the link test, in addition to the one you are
> > checking.  You should simply write the test as:
> >
> >   AC_SEARCH_LIBS([h5open_f],[hdf5_fortran])
>
> Yep you're right about this, and I probably should have explained
> this. I already knew that I was "cheating" by doing this.

By cheating, in this fashion, you are injecting the -L... flag into the 
test command, *after* the name of the library you are checking for; 
this comes too late for it to influence the search path which will be 
used to find that library.

> But if I dp what you sugggest then I just 
> get another kind of error about the linker not being able to find the
> library in the first place. I just put it in there because I knew it
> needed to be in the command and at the moment that's the only way
> I've been able to make that happen (for more on this continue
> reading).
>
> > then specify the proper LDFLAGS, and maybe also FFLAGS, (or
> > whatever the appropriate variable for specifying compiler flags to
> > be passed to your FORTRAN compiler is called), when you run
> > configure:
> >
> >   path/to/configure FFLAGS='...' LDFLAGS='-L/path/to/my/libs' ...
>
> This would be fine, if I could get autoconf to give me a configure
> script that knows how to properly test for the  presence of the
> library. AC_SEARCH_LIBS doesn't know that the -L flag needs to be
> there.

No, but it *does* inject the expansion of $LDFLAGS, at the appropriate 
position in the command line, to grant it that knowledge.  This snippet 
in configure.ac:

  AC_INIT
  AC_PROG_FC
  AC_LANG([Fortran])
  AC_SEARCH_LIBS([foo],[foobar])

generates a configure script, (using autoconf-2.61), which defines:

  ac_link='$FC -o conftest$ac_exeext $FCFLAGS $LDFLAGS
     $ac_fcflags_srcext conftest.$ac_ext $LIBS >&5'

(the line wrap is mine, for readability), and that command is what is 
subsequently executed, within AC_SEARCH_LIBS, when searching for the 
required library.  Thus, if you've followed my advice, and properly 
specified LDFLAGS when you invoke configure, that *should* pass the 
correct search path in the command line invoked by AC_SEARCH_LIBS, and 
it should behave just the same as when you invoke this linking command 
yourself, from the command line.

> The same holds for the -I.

Same philosophy; you should specify it in FCFLAGS, when you invoke 
configure.

> > Note that the `-I' specification doesn't belong in LDFLAGS; if you
> > need it, it should go in CPPFLAGS, (for C/C++), and I guess the
> > equivalent would be FFLAGS for FORTRAN.  (These are all flags which
> > should be left for the user to specify, when running configure).
>
> Right again, and I do have CPPFLAGS specified in my source
> Makefile.am. The point is that it needs to be in the command that the
> test configure runs to find the library.

Well, CPPFLAGS is irrelevant for FORTRAN; you should use FCFLAGS.  
However, for the test program used by AC_SEARCH_LIBS, this should be 
immaterial, for it doesn't need to include anything from user space, so 
there is no need for any -I... specification.

> If it's not there the test fails. And the point of the test is to tell
> autoconf what values to put into LDFLAGS which is what I'm really
> trying to accomplish.

You *don't* tell *autoconf* what values to put in LDFLAGS; the *user* 
tells *configure* what is appropriate for his platform.  You shouldn't 
try to second guess him on that, for you know nothing of the details of 
his platform installation.

> I know all this to be true because
> I've tried all variations on the command and they all make g95
> complain except one. Namely,
>
> g95 -g -o conftest -O2 -L/Users/tjd/local/lib -lhdf5_fortran -lhdf5
> -lz -I/Users/tjd/local

So, to get to that same command, within the scope of AC_SEARCH_LIBS, you 
need to use, (as you had originally):

  AC_SEARCH_LIBS([h5open_f],[hdf5_fortran],[],[],[-lhdf5 -lz])

*and* you need to add an appropriate `LDFLAGS=/path/for/hdf5_fortran' to 
your *configure* command line, when you run it.

> really this is the only one that works and then only if the test
> program has the use statement and an integer argument for the
> function.

I've already explained why it is *wrong* to include the use statement;
by doing so, you change the focus of the test from checking for the 
availability of a library which provides `h5open_f', making it instead 
become a check of the syntax of a call to that subroutine or function, 
in terms of its declared prototype.  This is *not* what AC_SEARCH_LIBS 
is about.  Unless the entry point name for `h5open_f' in the object 
library  is influenced by the number of arguments it expects, there is 
absolutely no need for AC_SEARCH_LIBS to have any knowledge of the 
expected call syntax; the simple test program it uses:

  program main
  call h5open_f
  end

is *exactly* what is required, and appropriate, to satisfy the objective 
of the test; to attempt to specify it otherwise would rob the test of 
its generality, and degrade the usefulness of the AC_SEARCH_LIBS macro.

OTOH, if you really do need to give the test program knowledge of the 
expected calling syntax, then you can't use a generalised test, such as 
AC_SEARCH_LIBS; you will need to write your own specialised variant, 
perhaps using AC_LANG_PROGRAM and AC_LINK_IFELSE instead.

Regards,
Keith.