Thursday, February 22, 2024
rated 0 times [  1] [ 0]  / answers: 1 / hits: 3220  / 3 Years ago, thu, june 24, 2021, 3:35:00

I ran into errors in the installation of the FDTD software MEEP on Ubuntu.Although I have hdf5-tools and libhdf5 installed on my system(Ubuntu 14.04.1 64-bit), the make step of the installation of MEEP returns an error as in this paste.bin link. I configured MEEP with the following command:

./configure --with-mpi --with-hdf5=/usr/lib/x86_64-linux-gnu/  > configure.out

I then ran make which resulted in error and I could not run make install afterwards. Without specifying the --with-hdf5 flag the configuration script used to return a warning as follows:

configure: WARNING: Couldn't find the HDF5 library!! Switching to ...

After installing numerous HDF5 libraries the problem was magically resolved; however, it was still present when I used the flag --with-hdf5=/usr/lib/x86_64-linux-gnu/. But without the flag everything installed flawlessly(I tested the program afterwards and confirmed that it was running as expected.) except the GNU Scientific Library linkage. My questions are as follows:

  1. How the location of the library can be located from the command prompt? Is executing the command locate hdf5 in the case of HDF5 and the finding the path of files ending with .so, .a enough?

  2. How could the GNU Scientific Library be introduced to the configuration and make scripts?

  3. Do the environmental variables LDFLAGS, CPPFLAGS and LD_LIBRARY_PATH have anything to do with the configuration and make scripts recognizing these libraries. I think they have since they are mentioned in MEEP install instructions and MEEP install tutorial. I would appreciate it if someone can explain how these and the LIB variable are related with installation procedures.

Thanks for taking your time,

P.S: If required I can supply additional documents. I did not put the configuration script etc. since I do not know which one is automatically generated and which one is not(same goes for make).

More From » software-installation


To answer this question well really requires a thorough understanding of GNU autotools, which I don't have: nevertheless I hope these comments will help.

The configure script for a particular build is generated from its file using autoconf. In turn, uses standard macros to test for the presence of specified components. In this particular case, specifies an AC_CHECK_LIB test for the GSL library as

  AC_CHECK_LIB(gsl, gsl_sf_bessel_Jn, [],
[AC_MSG_WARN([Missing GNU GSL library...Bessel-function field initialization will not be supported.])])

The syntax of an AC_CHECK_LIB is

AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])

and the actual mechanism by which the check is performed is by creating a minimal test program (conftest) for the specified function gsl_sf_bessel_Jn in library libgsl, and attempting to link it using the default build tools. Such a minimal program might look something like

char gsl_sf_bessel_Jn();

int main() { return gsl_sf_bessel_Jn(); return 0; }

Note that the dummy prototype char gsl_sf_bessel_Jn() may bear no relation to the return type or argument list of the actual function - we never attempt to run the program, we just wish to know whether it links (i.e. whether the linker is able to resolve library references). We can see how this works if we create such a source file ourselves:

$ cat > conftest.c
char gsl_sf_bessel_Jn();

int main() { return gsl_sf_bessel_Jn(); return 0; }


As expected, if we try to run it without linking the GSL library, we get an error

$ gcc conftest.c
/tmp/ccWqFraS.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `gsl_sf_bessel_Jn'
collect2: error: ld returned 1 exit status

However even if we explicitly link libgsl we find

$ gcc conftest.c -lgsl
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/ undefined reference to `cblas_dasum'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/ undefined reference to `cblas_sger'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/ undefined reference to `cblas_zdotu_sub'
collect2: error: ld returned 1 exit status

At this point, it's important to note that the configure script doesn't know why a particular test has failed, only that it has. In this case, it has failed because we didn't link the subordinate libgslcblas library.

This illustrates the importance of the order in which tests are performed: each successful test causes the newly discovered library to be added to the $LIB variable for subsequent tests. Specifically (as noted in the GSL documentation)

It is important to check for libm and libgslcblas before libgsl,
otherwise the tests will fail. Assuming the libraries are found the
output during the configure stage looks like this,

checking for cos in -lm... yes 
checking for cblas_dgemm in -lgslcblas... yes
checking for gsl_blas_dgemm in -lgsl... yes

If the library is found then the tests will define the macros
HAVE_LIBGSL, HAVE_LIBGSLCBLAS, HAVE_LIBM and add the options -lgsl
-lgslcblas -lm to the variable LIBS.

The meep source package does check for libgslcblas before libgsl, however the specific check that it does is an AC_CHECK_FUNC rather than an AC_CHECK_LIB

AC_CHECK_FUNC(cblas_cgemm, [], [AC_CHECK_LIB(gslcblas, cblas_cgemm)])

While superficially similar, it appears that AC_CHECK_FUNC does not append the library to $LIBS on success; it appears we can work around this simply by adding an explicit AC_CHECK_LIB for libgslcblas in the file

# GNU Scientific Library
AC_CHECK_FUNC(cblas_cgemm, [], [AC_CHECK_LIB(gslcblas, cblas_cgemm)])
AC_CHECK_LIB(gsl, gsl_sf_bessel_Jn, [],
[AC_MSG_WARN([Missing GNU GSL library...Bessel-function field initialization will not be supported.])])

and then running autoconf to regenerate the configure script

$ autoconf

after which running ./configure reports that the the GSL library is indeed found:

$ ./configure --prefix=/usr/local | grep gsl
configure: WARNING: Cannot find latex2html in your path!
configure: WARNING: FFTW needed for MPB
checking for cblas_cgemm in -lgslcblas... yes
checking for gsl_sf_bessel_Jn in -lgsl... yes

[#22024] Friday, June 25, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.

Total Points: 169
Total Questions: 105
Total Answers: 141

Location: Sao Tome and Principe
Member since Wed, Dec 29, 2021
2 Years ago