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

 
 

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

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Sun 05 Aug 2012 02:44:05 PM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: None
Originator Name: Ben AbbottOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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:

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>
Project Administrator
Mon 10 Sep 2012 08:14:33 PM UTC, comment #16:

Thanks. While I recompile everything, I noticed this:

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>
Project 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>
Project 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:

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>
Project Administrator
Mon 10 Sep 2012 05:31:19 PM UTC, comment #11:

Since this changeset, compilation fails on my system with:

on OpenSuse 11.3 with these packages:

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

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>
Project 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>
Project 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>
Project Administrator
Fri 07 Sep 2012 06:21:29 PM UTC, comment #7:

My LDFLAGS is set as indicated below.

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>
Project 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>
Project 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>
Project 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>
Project 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:

Rik <rik5>
Project 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>
Project Member
Mon 06 Aug 2012 02:18:28 AM UTC, comment #1:

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

If built without the SuiteSparse lib I get;

If built with the SuiteSparse library there is no error.

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>
Project 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)

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>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 11 Sep 2012 02:51:53 PM UTCrik5Open/ClosedOpen=>Closed
    Mon 10 Sep 2012 09:17:30 PM UTCrik5Attached File-=>Added configure.ac, #26524
    Mon 10 Sep 2012 07:54:30 PM UTCrik5Open/ClosedClosed=>Open
    Sat 08 Sep 2012 02:57:27 AM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Fri 07 Sep 2012 09:45:27 PM UTCrik5Attached File-=>Added umfpack_config.cset, #26502
      StatusNone=>Patch Submitted

    Back to the top


    Powered by Savane 3.1-cleanup