bugGNU Octave - Bugs: bug #37031, Building Octave with...

 
 

bug #37031: Building Octave with SuiteSparse-4.x.x

Submitter:  Ben Abbott <bpabbott>
Submitted:  Sun 05 Aug 2012 02:44:05 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Ben Abbott Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 11 Sep 2012 02:51:53 PM UTC, comment #19: 

Yes, the internal structure of Octave has been changing quite a bit and libcruft no longer exists.  Re-compiling your MEX files will solve this.  I will submit the patch that worked for you and close this bug report.

 Rik <rik5>
Group administrator
Tue 11 Sep 2012 11:15:19 AM UTC, comment #18: 

With this configure.ac it compiles fine.

I now get errors with my own MEX files:

failed to load: libcruft.so.1: cannot open shared object file: No such file or directory


but I guess it is not related  and might be a consequence of the 'make maintainer-clean' so I'm going to recompile my MEX files.

 Guillaume <gyom>
Mon 10 Sep 2012 09:17:30 PM UTC, comment #17: 

Your build is probably going to fail.  I've attached a configure.ac which I believe will work with ancient versions of SuiteSparse.  It links in the AMD and BLAS libraries when doing the tests in configure.  Try replacing your existing configure.ac with the one I am attaching to this bug report.  You will then need to do the 'autogen.sh; configure' sequence.  If it works I will commit the change.

(file #26524)

 Rik <rik5>
Group administrator
Mon 10 Sep 2012 08:14:33 PM UTC, comment #16: 

Thanks. While I recompile everything, I noticed this:


configure:34047: checking whether UMFPACK needs SuiteSparse_time function
configure:34090: gcc -o conftest -g -O2 -pthread   conftest.c -lumfpack  -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../.. -lgfortran -lm -lm   >&5
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_l_valid'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_printf'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_valid'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_1'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_postorder'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_l_defaults'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_free'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_l_postorder'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_l1'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_realloc'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_defaults'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_malloc'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_l_aat'
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libumfpack.so: undefined reference to `amd_aat'
collect2: ld returned 1 exit status


 Guillaume <gyom>
Mon 10 Sep 2012 07:54:30 PM UTC, comment #15: 

It is possible that there is something wrong with the patch and version 3.2.  I tested the patch with version 3.4 and 4.0, but didn't have an easy way to test 3.2.

I would suggest removing 4.0 from the system so you are back to a stable distribution-only set of packages.  After than, run 'make maintainer-clean'.  That should really remove any trace of your current build.  Then run 'autogen.sh' to recreate the configure script.  Finally run 'configure' with your default set of options.  In other words, don't add any special options like --with-umfpack.  This will produce a file called config.log.  If you can upload the config.lig file to this bug reporti I will check it for problems.

 Rik <rik5>
Group administrator
Mon 10 Sep 2012 07:18:32 PM UTC, comment #14: 

Thanks for your help.

What happened is that until now, SuiteSparse was installed as a package from my Linux distribution: version 3.2 in /usr/include/suitesparse and /usr/lib64/lib* and I could compile Octave without having to specify to ./configure where it was installed.

Then, since last week, I got the errors during compilation as reported below. I though that the problem was that SuiteSparse 4 was now required. As it is not available as a package for my 'old' distrib, I installed it manually from SuiteSparse-4.0.2.tar.gz in /home/me/opt/SuiteSparse and managed to successfully compile Octave by adjusting CPPFLAGS and LDFLAGS; but it didn't work when using --with-umfpack-includedir and --with-umfpack-libdir.

I understand it is a bad setting to have SuiteSparse installed twice but initially I only got it installed once (3.2) and compilation fails there following recent changes.

Could there be something in the change that allows compilation with SuiteSparse 4.0 that prevents to use 3.2?

 Guillaume <gyom>
Mon 10 Sep 2012 05:57:12 PM UTC, comment #13: 

One other thought, did your LDFLAGS variable really get set correctly with the extra -L option for the link path.  If you look at the compile line which is failing you can see that there is no '-L/home/me/opt/SuiteSparse/lib' in the command.  It truly can't find the library which is why it is failing.

 Rik <rik5>
Group administrator
Mon 10 Sep 2012 05:52:03 PM UTC, comment #12: 

My guess is that the build system is getting confused over which SuiteSparse to build with (3.2 or 4.0).  SuiteSparse 4.0 is not required to build Octave.  The bug fix only made it possible to compile with SuiteSparse 4.0 if you wanted to.

There are a couple of options

1) Try removing the 3.2 version and re-running 'sh autogen.sh; ./configure' cycle.  See if the build system picks up the new 4.0 libraries correctly.  Or try removing the 4.0 libraries and re-running 'sh autogen.sh; ./configure' if you want to keep the 3.2 version.

2) Or you could try using the with-umfpack options to specify where files are located.  The options are:


  --with-umfpack-includedir=DIR
                          look for UMFPACK include files in DIR
  --with-umfpack-libdir=DIR
                          look for UMFPACK libraries in DIR


Note that it is probably a really bad idea to bring in only the 4.0 umfpack libraries and keep the other libraries, such as amd, at the 3.2 versions.  Unfortunately, this would mean using a host of with-xxx-includedir and --with-xxx-libdir options.  Try './configure --help' to see just how many libraries are related to SuiteSparse.  This is why I suggested just removing the SuiteSparse library version that you don't want.



Rik <rik5>
Group administrator
Mon 10 Sep 2012 05:31:19 PM UTC, comment #11: 

Since this changeset, compilation fails on my system with:


libtool: link: g++ -g -O2 -pthread -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread -o .libs/octave octave-main-cli.o  ../libinterp/.libs/liboctinterp.so -L/usr/lib64 /home/me/opt/octave/liboctave/.libs/liboctave.so -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../.. -lhdf5 -lz -lX11 ../liboctave/.libs/liboctave.so -lcholmod -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lfftw3 -lfftw3f -llapack -lblas -lreadline -lncurses -lpcre -ldl -lgfortran -lutil -lm -pthread -Wl,-rpath -Wl,/home/me/opt/octave_install/lib/octave/3.7.0+
/home/me/opt/octave/liboctave/.libs/liboctave.so: undefined reference to `umfpack_zi_get_determinant'
/home/me/opt/octave/liboctave/.libs/liboctave.so: undefined reference to `umfpack_zi_defaults'
/home/me/opt/octave/liboctave/.libs/liboctave.so: undefined reference to `umfpack_di_report_info'
...


on OpenSuse 11.3 with these packages:


libumfpack5              5.2.0-8.1
umfpack-devel            5.2.0-8.1

suitesparse              3.2.0-12.1
suitesparse-common-devel 3.2.0-5.1
suitesparse-devel        3.2.0-12.1


I manually installed SuiteSparse 4.0.2 and added its location to ./configure

CPPFLAGS=-I/home/me/opt/SuiteSparse/include/ LDFLAGS=-L/home/me/opt/SuiteSparse/lib


Does Octave compilation now require SuiteSparse >=4 ? and what is the appropriate syntax for ./configure? I tried --with-umfpack-* instead of changing CPPFLAGS and LDFLAGS but it didn't work.

 Guillaume <gyom>
Sat 08 Sep 2012 02:57:27 AM UTC, comment #10: 

Applied the fix in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/719ffb2f35a6).

 Rik <rik5>
Group administrator
Fri 07 Sep 2012 10:58:40 PM UTC, comment #9: 

Rik,

You changeset works for me.  I tested it on the default branch (tip = 15321:5ddeef055df3)


Ben Abbott <bpabbott>
Group Member
Fri 07 Sep 2012 09:45:27 PM UTC, comment #8: 

Ben, I've attached a complex patch that works for me on Linux.  If you could test it on a Mac and certify it then I will commit it.

(file #26502)

 Rik <rik5>
Group administrator
Fri 07 Sep 2012 06:21:29 PM UTC, comment #7: 

My LDFLAGS is set as indicated below.


LDFLAGS="-headerpad_max_install_names -D_THREAD_SAFE -L/opt/local/lib"


The header pad thing is needed to make creating an App bundle on MacOS more robust (adds maximum room for changing the install names).

I do not have librt on my system.

 Ben Abbott <bpabbott>
Group Member
Fri 07 Sep 2012 05:58:48 PM UTC, comment #6: 

Ben, I tried your test program with your exact compile command and I wasn't able to get it to work without adding '-lrt' which links in a library for the clock_gettime function.

Do you have librt on your system?  Did you have some other environment variables like LDFLAGS set at the time you ran your compile?

 Rik <rik5>
Group administrator
Fri 07 Sep 2012 05:51:49 PM UTC, comment #5: 

For others happening on this thread, the work-around on Linux platforms is to use

--with-umfpack="-lumfpack -lsuitesparseconfig"

during the configure process.

 Rik <rik5>
Group administrator
Thu 06 Sep 2012 11:48:04 PM UTC, comment #4: 

Rik

I haven't checked, but I assume the problem is independent of OS.  What I don't know is how the name of the SuiteSparse library changes.

 Ben Abbott <bpabbott>
Group Member
Thu 06 Sep 2012 11:26:14 PM UTC, comment #3: 

Ben,

I've been working a bunch on improving the build system and I can create a test in configure.ac for this SuiteSparse issue.

Is this only an issue on Mac OS X platforms?  Should I put a test on canonical host like so:


  case "$canonical_host_type" in
    *-*-darwin*)
      OCTAVE_UMFPACK_NEED_SUITESPARSE
      ;;




 Rik <rik5>
Group administrator
Mon 06 Aug 2012 09:56:30 PM UTC, comment #2: 

A simple work around it to add the configure script option below

--with-umfpack="-lumfpack -lSuiteSparse"


Ben Abbott <bpabbott>
Group Member
Mon 06 Aug 2012 02:18:28 AM UTC, comment #1: 

I have a test program (below) that looks to do the job.


#include "umfpack.h"
int
main ()
{
  double stats [2];
  umfpack_tic (stats);
  umfpack_toc (stats);
  return 0;
}


If built without the SuiteSparse lib I get;


$ gcc -o conftest conftest.cc -I/opt/local/include -L/opt/local/lib  -lumfpack
Undefined symbols for architecture x86_64:
  "_SuiteSparse_time", referenced from:
      _umfpack_tic in libumfpack.a(umfpack_gn_tictoc.o)
      _umfpack_toc in libumfpack.a(umfpack_gn_tictoc.o)
ld: symbol(s) not found for architecture x86_64


If built with the SuiteSparse library there is no error.


$gcc -o conftest conftest.cc -I/opt/local/include -L/opt/local/lib -lumfpack -lSuiteSparse


Looks like this will be easy to use to create a changeset to allow Octave to link against SuiteSparse 4.0.x.  I have a busy schedule and may not get to this quickly.  If anyone is in a hurry, please feel free to take this on.

 Ben Abbott <bpabbott>
Group Member
Sun 05 Aug 2012 02:44:05 PM UTC, original submission:  

Building Octave with SuiteSparse-4.0.2 I still encounter the errors below (during the link phase for liboctave)


Undefined symbols for architecture x86_64:
"_SuiteSparse_time", referenced from:
    _umfpack_tic in libumfpack.a(umfpack_gn_tictoc.o)
    _umfpack_toc in libumfpack.a(umfpack_gn_tictoc.o)


When building liboctave it is necessary to link to both libumfpack.a and libSuiteSparse.dylib.  By manually editing the Makefile for liboctave and addeding -lSuiteSparse to the UMFPACK_LIBS variable liboctave and octave are able to build.  Running "make check" produced no new failures.

The proper place to fix this is in the configure script.  A simple test program is needed.

 Ben Abbott <bpabbott>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #26524:  configure.ac added by rik5 (82KiB - application/octet-stream)
file #26502:  umfpack_config.cset added by rik5 (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-09-11 rik5 Open/ClosedOpen Closed
    2012-09-10 rik5 Attached File- Added configure.ac, #26524
    2012-09-10 rik5 Open/ClosedClosed Open
    2012-09-08 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2012-09-07 rik5 Attached File- Added umfpack_config.cset, #26502
        StatusNone Patch Submitted

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-d582.
    Corresponding source code