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: tdennis@xxxxxxxxxxxxxxxxx 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: tdennis@xxxxxxxxxxxxxxxxx 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
