Unable to run configure: Could not locate libraries for the following symbols: dsyev_. about jblas HOT 7 OPEN

Hi Maxim,

When building atlas, have you specified that it should include a full lapack library? Atlas then combines both its own routines and those from liblapack. That should do the trick. Sorry don't remember how exactly that is done with the atlas build scripts.

-M

----- Ursprüngliche Nachricht -----
Von: "Maxim Mai" [email protected]
Gesendet: ‎23.‎07.‎2015 11:16
An: "mikiobraun/jblas" [email protected]
Betreff: [jblas] Unable to run configure: Could not locate libraries for thefollowing symbols: dsyev_. (#66)

Hi, I keep getting this error on x86_64 Ubuntu when I try to build jblas from source. I looked at the config file located in config/config_libs.rb to see why dsyev_ is needed, but the part dsyev_ is a required symbol, but not yet included in ATLAS/LAPACK confuses me:
ATLAS_REQUIRED_SYMBOLS = [
'dsyev_', # eigenvalue function not yet included in ATLAS/LAPACK
'ATL_dgemm',
'dgemm_', # matrix-matrix multiplication
'daxpy_', # blas-related function
'cblas_daxpy', # atlas itself often uses cblas
'ATL_caxpy'
]
I downloaded ATLAS 3.10.2 from http://downloads.sourceforge.net/project/math-atlas/Stable/3.10.2/atlas3.10.2.tar.bz2 then compiled it using the default build parameters.
In the jblas working directory, I run ./configure --libpath=$HOME/jblas/dep/ATLAS/build/lib --static-libs
In my $HOME/jblas/dep/ATLAS/build/lib, it contains the following libraries:
libatlas.a libcblas.a libf77blas.a libf77refblas.a liblapack.a libptcblas.a libptf77blas.a libptlapack.a libtstatlas.a
I checked all the .a files there with nm:
nm $HOME/jblas/dep/ATLAS/build/lib/.a | grep "dsyev_"
Found nothing in those libraries that has this symbol.
Please clarify if this is an intended requirement for the build.
Environment: Ubuntu 14.04, [email protected] x86_64
—
Reply to this email directly or view it on GitHub.

from jblas.

Hello Mikio,

I am still not able to configure jblas with ATLAS, however, I was able to manage get it configured with LAPACK through the option of "./configure --download-lapack".

However, the LAPACK comes with the configure program has a bug for the 64bit Linux I have on IBM's z System. in config/config_libs.rb:

    if CONFIG['OS_NAME'] == 'Linux' and CONFIG['OS_ARCH'] == 'amd64'
      CONFIG['LOADLIBES'] += ['-lgfortran']
      puts <<EOS
    elsif CONFIG['OS_NAME'] == 'Mac\ OS\ X'
      print "Looking for where libgfortran.a is... "
      libgfortran_path = %x(gfortran -print-file-name=libgfortran.a).strip
      puts "(#{libgfortran_path})"
      CONFIG['LOADLIBES'] += [libgfortran_path]
    else
      CONFIG['LOADLIBES'] += ['-l:libgfortran.a']

There is a warning in this code block:

WARNING: on 64bit Linux, I cannot link the gfortran library into the shared library
because it's usually not compiled with -fPIC. This means that you need to
have libgfortran.so installed on your target system. Sorry for the inconvenience!
EOS.

This config_libs.rb result a configure.out for Linux on z that contains:

LOADLIBES=-Wl,-z,muldefs ./lapack-lite-3.1.1/liblapack.a ./lapack-lite-3.1.1/libblas.a -l:libgfortran.a

This is problematic because we found that when we use this jblas in Spark, it's failing the MLlib test because init_integer from libgfortran can not find the return address (simply because the jblas wasn't configured with -fPIC and -lgfortran).

The correct LOADLIBES should be:

LOADLIBES=-Wl,-z,muldefs ./lapack-lite-3.1.1/liblapack.a ./lapack-lite-3.1.1/libblas.a -lgfortran

Do you suggest to use this work item to update config_libs.rb to cover Linux on z (OS_NAME=LINUX and OS_ARCH=s390x)?

Thanks!

from jblas.

Hi Maxim,

if that fixes the issue on s390x, I have no problems to add that to the
config file.

Yeah, I should probably rethink the whole libgfortran binding policies in
64bit Linux. Back when I started jblas, 64 bit systems weren't the norm,
but now I think probably everyone uses them, and the handling should be
more streamlined!

If you could add the right rules to the config_libs.rb and send me a pull
request, I can merge your fix!

Best,

-M

On Mon, Oct 5, 2015 at 11:52 PM, Maxim Mai [email protected] wrote:

Hello Mikio,

I am still not able to configure jblas with ATLAS, however, I was able to
manage get it configured with LAPACK through the option of "./configure
--download-lapack".

However, the LAPACK comes with the configure program has a bug for the
64bit Linux I have on IBM's z System. in config/config_libs.rb:

if CONFIG['OS_NAME'] == 'Linux' and CONFIG['OS_ARCH'] == 'amd64'
  CONFIG['LOADLIBES'] += ['-lgfortran']
  puts <<EOS
elsif CONFIG['OS_NAME'] == 'Mac\ OS\ X'
  print "Looking for where libgfortran.a is... "
  libgfortran_path = %x(gfortran -print-file-name=libgfortran.a).strip
  puts "(#{libgfortran_path})"
  CONFIG['LOADLIBES'] += [libgfortran_path]
else
  CONFIG['LOADLIBES'] += ['-l:libgfortran.a']

There is a warning in this code block:

WARNING: on 64bit Linux, I cannot link the gfortran library into the
shared library
because it's usually not compiled with -fPIC. This means that you need to
have libgfortran.so installed on your target system. Sorry for the
inconvenience!
EOS.

This config_libs.rb result a configure.out for Linux on z that contains:

LOADLIBES=-Wl,-z,muldefs ./lapack-lite-3.1.1/liblapack.a ./lapack-lite-3.1.1/libblas.a -l:libgfortran.a

This is problematic because we found that when we use this jblas in Spark,
it's failing the MLlib test because init_integer from libgfortran can not
find the return address (simply because the jblas wasn't configured with
-fPIC and -lgfortran).

The correct LOADLIBES should be:

LOADLIBES=-Wl,-z,muldefs ./lapack-lite-3.1.1/liblapack.a ./lapack-lite-3.1.1/libblas.a -lgfortran

Do you suggest to use this work item to update config_libs.rb to cover
Linux on z (OS_NAME=LINUX and OS_ARCH=s390x)?

Thanks!

—
Reply to this email directly or view it on GitHub
#66 (comment).

Mikio Braun - http://blog.mikiobraun.de, http://twitter.com/mikiobraun

from jblas.

Sorry, finally getting back to this project, let me have a look.

from jblas.

Trying to build jblas from source per #115, but running into this same issue around the missing symbols. --download-lapack doesn't seem to do anything.

from jblas.

from jblas.

Yup, that worked perfectly. I updated the other issue as well, but wanted to express thanks on here and note that it works when following your instructions.

from jblas.