3

Situation

I work with Ubuntu 14.04. I am building GNU Octave 4.2.1 from source with GNU 6.3.0. This version of Octave is quite new, but I see the issue arising also when trying to compile older Octave releases (down to 3.8.1).

I configure the build of Octave with

${sourcedir}/configure --prefix=/opt/octave/4.2.1 \
--with-java-homedir=/usr/lib/jvm/default-java \
--with-java-libdir=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server

Issue

The compilation is successful but the undesired warning shows up

configure: WARNING: ARPACK library found, but does not seem to work properly; disabling eigs function

I would rather like to have the eigs() function in place.

Information

I have built ARPACK-ng myself with the same compiler. All tests in the test suite (make check) are passed. The environment variables LD_LIBRARY_PATH and PKG_CONFIG_PATH point to the ARPACK library directory as intended. The configure file of Octave recognizes that location correctly, as seen before.

Besides, I get the same message if I compile Octave in another computer where ARPACK is installed natively (libarpack2 and libarpack2-dev version 3.1.5-2). It does not change a thing if I also install the related extra libraries libarpack++2c2a and libarpack++2-dev using the package repository. So the issue appears to be independent of the origin of the ARPACK files.

The part of the configure.ac file of Octave that throws this error is

### Check for ARPACK library.

save_LIBS="$LIBS"
LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS"
OCTAVE_CHECK_LIB([arpack], ARPACK,
[ARPACK not found.  The eigs function will be disabled.],
[],
[dseupd],
[Fortran 77], [don't use the ARPACK library, disable eigs function],
[warn_arpack=
OCTAVE_CHECK_LIB_ARPACK_OK(
[AC_DEFINE(HAVE_ARPACK, 1, [Define to 1 if ARPACK is available.])],
[warn_arpack="ARPACK library found, but does not seem to work properly; disabling eigs function"])])
LIBS="$save_LIBS"

The farthest I go in tracing back the issue is that the subroutine OCTAVE_CHECK_LIB_ARPACK_OK issuing the warning lives in the file ${octave_source}/m4/acinclude.m4. It is written in m4 language, which I don't know

Question

Is it possible to understand why ARPACK 'does not seem to work properly'?

Is there any workaround for this?

Is this a false alarm or a bug?

XavierStuvw
  • 1,294
  • 2
  • 15
  • 30
  • I assume this `configure` is an autotools-style `configure`. Did you check `config.log`? – uzsolt Mar 05 '17 at 08:30
  • @uzsolt Yes it is and yes I had. The config.log that exits with status 0 and is little bothered (we are dealing with warnings, after all). I shall add that in the meantime, after a little head-banging, I isolated the cause of the issue in the gcc compiler, which had been built from source as well. I still have to formulate the issue properly, will ask in a separate post and come back with my solution. – XavierStuvw Mar 05 '17 at 14:24
  • Did you ever come up with a solution to this problem. I am experiencing the same issue on CentOS 6.6 – irritable_phd_syndrome Apr 17 '17 at 11:53
  • @irritable_phd_syndrom My evidence is that the arpack libraries are not included if I compile Octave with my own gcc passing CC or CXX as environment variables to the configure command for Octave. Rather, if I only use my own gcc for CPP and/or FC/F77, then arpack is included. Likewise, if I use the native gcc, arpack is included. In sum, the problem seems to be caused, at least, by some dislike for my own C and C++, but I haven't investigated this further. Hope this helps a bit. – XavierStuvw Jun 06 '17 at 11:52

0 Answers0