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

[Tim Dennis]

Hi Keith,


> On Sunday 16 March 2008 01:27, Tim Dennis wrote, quoting me:

> 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.

FWIW This does not appear to be true for the g95 compiler/linker. If I go
into my source directory and enter:

g95 -I/Users/tjd/local/lib -g -O2 -c -o test test.o test.f90
g95 -I/Users/tjd/local/lib -g -O2 -o test test.o -lhdf5_fortran -lhdf5 -lz
-L/Users/tjd/local/lib

the compiler creates an executable without complaint. Perhaps the order of
-L's and -l's matters for other compilers. Please understand that I'm
aware that the whole point of autoconfiscation is to make a package
portable. In fact this is why I'm trying to learn it in the first place. 
This was a temporary cheat put in at a time before I understood the proper
way to deal with LDFLAGS as you've since explained to me. I'm not using
this anymore.

> 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.

Yes, I'm clear now on these issues LDFLAGS FCLAGS and so on are all
user-assigned variables, assigned when the configure script is run. You
have helped me here. Please read on...


>> 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 was a bit confused over the meanings of LIBS and LDFLAGS when I wrote
this. I now understand that it is LIBS that I'm trying to "tell" autoconf
about. As for my use of the word "tell," this was intended as a shorthand
for what I really meant: namely putting a check into configure.ac that
would serve the purpose of assigning the needed value to LIBS (as opposed
to LDFLAGS) namely
"-lhdf5_fortran".  It is my understanding that this is the default action
for AC_SEARCH_LIBS if the test is passed. In this sense, the check "tells"
autoconf, or perhaps I should be saying "configure," that LIBS should have
this library added.


> 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.

Yes, I understand that this is what you've been trying to tell me, but I'm
sorry Keith, it just doesn't work.  Allow me to provide some detail here.
The very line that you suggest above is in fact what I currently have in
my configure.ac file, and the lines:

 AC_PROG_FC
 AC_LANG([Fortran])

also appear there prior to the AC_SEARCH_LIBS line.

When I invoke configure I do so as follows (as per your instructions)

./configure FC=g95 LDFLAGS=-L/Users/tjd/local/lib
FCFLAGS=/Users/tjd/local/lib --prefix=/Users/tjd/local

but the test fails. When I look in config.log I find the following
compiler/linker commands:

g95 -o conftest -I/Users/tjd/local/lib -L/Users/tjd/local/lib conftest.f

g95 -o conftest -I/Users/tjd/local/lib -L/Users/tjd/local/lib conftest.f
-lhdf5_fortran -lhdf5 -lz

one without the libary and one with, just as the manual describes: but
both tests fail with the
error:

ld: Undefined symbols:
_h5open_f__
...
configure:failed program was:
|       program main
|        call h5open_f
|       end

But, if I go to my source directory and apply the exact same command
(allowing for a slightly different source file name) to the test file
there
which is just:

program test
use hdf5
integer :: i
call h5open_f(i)
end program test

then I get an executable and no complaints about undefined symbols. It is
for this reason that I continue to think that the use statement needs to
be in the test.

> 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.

>From what I've been able to gather from my own experiments, the only way
in which the libary can be made available to my program (and therefore the
only way in which the test in configure has a hope of being passed), is by
including the use statement. I have to admit I don't see how what I'm
claiming is necessary, changes the focus to one of syntax checking. But
I'm not a software engineer/programmer by training, so there may be a gap
in my knowledge here.  My suspicion is that the issue has to do with what
my fortran book refers to as an "explicit interface,"
which may be what you mean by "function prototype."  I also speak c so I
know what a function
prototype is in that language and the fortran "explicit interface"
resembles it closely. My understanding is that there are circumstances in
which in order to access (i.e. link to a library containing)  a subroutine
that is defined outside a certain scope, there must be available an
explicit interface for that function. I think the hdf5.mod file provides
that interface. But I could be wrong.

>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:

Indeed, this is precisely what an explicit interface does. It makes
explicit the expected argument numbers and types.

> 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

Yup. This is the conclusion I've already come to. I've already mentioned
it in another thread actually.  I wound up with two threads on this
subject because I had initially got the impression that my first thread
was so vague in the way I expressed my question that no one was
responding. As it turns out I was just being impatient. My apologies if
this has caused confusion.

Anyway, Keith. Thanks for your help. Even though the problem isn't solved
yet I've learned a lot from our exchange.

Tim

-- 
Timothy J. Dennis                                email:
address@hidden
Research Associate                              office: 477 Bausch & Lomb
Hall
Department of Physics & Astronomy    Voice: 585-275-8556
University of Rochester                           Fax: 585-273-2813

Rochester, NY 14627





-- 
Timothy J. Dennis                                email:
address@hidden
Research Associate                              office: 477 Bausch & Lomb
Hall
Department of Physics & Astronomy    Voice: 585-275-8556
University of Rochester                           Fax: 585-273-2813

Rochester, NY 14627