bugGNU Octave - Bugs: bug #43063, Suitesparse 4.3.x has changed...

 
 

bug #43063: Suitesparse 4.3.x has changed APIs, no longer builds with Octave

Submitter:  marco atzeri <matzeri>
Submitted:  Sun 24 Aug 2014 06:20:37 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  mtmiller
Originator Name:  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 17 Feb 2015 04:17:09 PM UTC, comment #41: 

Thanks Sébastien, I'm able to build the current default branch against SuiteSparse 4.4.3-1 with no errors, so I'm closing this as it looks like it's fixed by cset afd6179d2616.

It would be nice to not have a version number check in oct-sparse.h, but that can be fixed later.

There is still a problem, "test eigs" hangs indefinitely for me with SuiteSparse 4.4.3, but I'll open a new bug about that.

 Mike Miller <mtmiller>
Group Member
Sat 14 Feb 2015 06:15:03 PM UTC, comment #40: 

Mike: I have uploaded SuiteSparse 4.4.3 to Debian experimental, but it is still waiting in the NEW queue. In the meantime, you can compile the package from the alioth VCS, or I can send you binary packages upon request.

 Sébastien Villemot <svillemot>
Sat 14 Feb 2015 05:35:12 PM UTC, comment #39: 

I am still on SuiteSparse 4.2.1, but I will try to take a look at building a newer version and see what still needs to be done to resolve this bug.

 Mike Miller <mtmiller>
Group Member
Sun 01 Feb 2015 08:15:04 PM UTC, comment #38: 

I just noticed that I left two instances of "SOEXT=dylib" hardcoded in two Makefiles covered by suitesparse-sharedlibs.patch in my recent upload, they are in subdirectories not used by octave, but should be eliminated for a clean patch. In the final version of my patch I set SOEXT dynamically to .dylib or .so in Makeconf at top level according to the architecture and then included in other Makefiles, but obviously I overlooked these two unused occurrences. 

Best regards,
Albrecht

 Albrecht Gebhardt <alge>
Sun 01 Feb 2015 07:07:18 PM UTC, comment #37: 

When I recently tried (and finally succeded) to compile octave 3.8.2 on an old PowerBook G4 running OS X 10.5.8 I stumbled upon these patches to cope with newer versions of SuiteSparse. I used 4.4.1 and the patches (downloaded in december) did not apply completely, so I had to fix at several places.

During this conversion I tried to make this a little bit cleaner and version independent, so  I will upload my patches here (SuiteSparse-4.4.1-patches.tar.gz) below.

With this patch both shared and static libraries will be build. It will also build correct library names on OS X and Linux, e.g. libamd.2.4.1.dylib with symlinks libamd.2.dylib and libamd.dylib and on Linux libamd.so.2.4.1 with symlinks libamd.so.2 and libamd.so and so on. I extended the deeper nested Makefiles so that they extract major und complete version numbers from the top level Makefiles and so on.

Maybe this is at least partially helpful,

Regards,
Albrecht



(file #32969)

 Albrecht Gebhardt <alge>
Fri 16 Jan 2015 09:09:29 PM UTC, comment #36: 

Something changed? I ask because i no longer need the patch for suitesparse.

 Stefan Husmann <haawda>
Thu 08 Jan 2015 10:40:40 PM UTC, comment #35: 

Arch Linux uses Suitesparse 4.4.1 now, and this seemed to retroduce the issue. I solved it with another patch for suitesparse.


(file #32792)

 Stefan Husmann <haawda>
Sun 04 Jan 2015 09:17:53 AM UTC, comment #34: 

@Andre: I have one recipe for Ubuntu Desktop with --enable-64 switch ... check this BLOG (http://calaba.tumblr.com/post/107087607479/octave-64) or this GitHub (https://github.com/calaba/octave-3.8.2-enable-64-ubuntu-14.04)

 richard <calaba>
Sat 04 Oct 2014 06:24:26 PM UTC, comment #33: 

Glad to hear it works for you.

Perhaps, I should post a detailed recipe on Octave wiki about how to install Octave from source on linux. May the maintainers be interested, please, let me know.

Regards,
André

 Andre da Costa Barros <andrecbarros>
Sat 04 Oct 2014 05:54:57 PM UTC, comment #32: 

Your concept works fine.

 Stefan Husmann <haawda>
Fri 03 Oct 2014 06:40:08 PM UTC, comment #31: 

Where you see /Include/.h , you instead should see

"*./Include/*.h"


(a preview before post would be good) :)

 Andre da Costa Barros <andrecbarros>
Fri 03 Oct 2014 06:35:37 PM UTC, comment #30: 

:)

Where you see /Include/.h you instead should see


"\./Include/\.h" -n

(did know about markups on this site, sorry)

 Andre da Costa Barros <andrecbarros>
Fri 03 Oct 2014 06:29:40 PM UTC, comment #29: 

OK, didn't know it. :)

Where you see /Include/.h you should see "\*./Include/\*.h". :\

Andre da Costa Barros <andrecbarros>
Fri 03 Oct 2014 06:21:45 PM UTC, comment #28: 

OK, it took some time because on my system I compile each piece of SuiteSparse (and install each) separately by scripts. Also, as it is and old Pentium Dual the testing phase is not that fast. :(

The patches are concatenated and compressed as they are a bit big. If it works on your system I may adjust it to make things a little easier to others that may be interested.

First step - patch and compile SuiteSparse
-------------------------------------------

After you decompress SuiteSparse and patches it, take a look on the differences between the original SuiteSparse_config.mk (inside SuiteSparse_config dir) and the modified one to see if it match the options you use on your system.

After you adjust things you may want, issue a "make". If everything went smooth, on the end of the process you will have all the shared libs on the base dir. Copy all of them to a place recognized by your linker, on my case, it is /usr/lib64.

Also, copy all /Include/.h to /usr/include/suitesparse. You should also copy SuiteSparse_config/SuiteSparse_config.mk to there. One thing, though, CSparse/Include/cs.h and CXSparse/Include/cs.h clashes so copy the first as cs0.h and, may you need to compile against libcsparse, don't forget to change your sources to '#include <cs0.h>' where appropriated. Octave compilation will not be affected by it (will be if you don't or if you do the reverse).

If you are like myself, you will actually prepare a package to your distribution and will install it.

Second step - compile Octave
----------------------------

In the following instructions, set the variable "metis_libs" to point to your metis library options. You can get it by issuing (on most systems):

  metis_libs=$( pkg-config --libs metis 2>/dev/null )

After you decompress Octave, prepare it to be configured with ./bootstrap by giving to it the following options:

  --with-amd="-lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt" \
  --with-camd="-lcamd -lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt" \
  --with-colamd="-lcolamd -lcamd -lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt" \
  --with-ccolamd="-lccolamd -lcolamd -lcamd -lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt" \
  --with-cholmod="-lcholmod -lccolamd -lcolamd -lcamd -lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt" \
  --with-umfpack="-lumfpack -lcholmod -lccolamd -lcolamd -lcamd -lamd $metis_libs -lsuitesparseconfig -lcerbla -lrt -llapack"

After that issue a make. May some error springs in the process or may you need extra assistance, post here the logs.

Regards,
André

ps1.: One of the patches, "suitesparse-config-bnc775418-enable-SuiteSparse_time-symbol.patch" is not mine and I didn't check if it is still needed.

ps2.: Added also the patches I use to compile Octave against latest version of SuiteSparse.


(file #32218, file #32219)

 Andre da Costa Barros <andrecbarros>
Wed 01 Oct 2014 09:17:27 PM UTC, comment #27: 

I use Arch Linux 64 bit (no version number available, this is a rolling release distro) and suitesparse 4.3.1 from the official repos. The package's contents is the following, whereas the unversioned libs are symlinks to the versioned counterparts.

suitesparse /usr/
suitesparse /usr/include/
suitesparse /usr/include/SuiteSparseQR.hpp
suitesparse /usr/include/SuiteSparseQR_C.h
suitesparse /usr/include/SuiteSparseQR_definitions.h
suitesparse /usr/include/SuiteSparse_config.h
suitesparse /usr/include/amd.h
suitesparse /usr/include/btf.h
suitesparse /usr/include/camd.h
suitesparse /usr/include/ccolamd.h
suitesparse /usr/include/cholmod.h
suitesparse /usr/include/cholmod_blas.h
suitesparse /usr/include/cholmod_camd.h
suitesparse /usr/include/cholmod_check.h
suitesparse /usr/include/cholmod_cholesky.h
suitesparse /usr/include/cholmod_complexity.h
suitesparse /usr/include/cholmod_config.h
suitesparse /usr/include/cholmod_core.h
suitesparse /usr/include/cholmod_gpu.h
suitesparse /usr/include/cholmod_gpu_kernels.h
suitesparse /usr/include/cholmod_io64.h
suitesparse /usr/include/cholmod_matrixops.h
suitesparse /usr/include/cholmod_modify.h
suitesparse /usr/include/cholmod_partition.h
suitesparse /usr/include/cholmod_supernodal.h
suitesparse /usr/include/cholmod_template.h
suitesparse /usr/include/colamd.h
suitesparse /usr/include/cs.h
suitesparse /usr/include/klu.h
suitesparse /usr/include/ldl.h
suitesparse /usr/include/spqr.hpp
suitesparse /usr/include/umfpack.h
suitesparse /usr/include/umfpack_col_to_triplet.h
suitesparse /usr/include/umfpack_defaults.h
suitesparse /usr/include/umfpack_free_numeric.h
suitesparse /usr/include/umfpack_free_symbolic.h
suitesparse /usr/include/umfpack_get_determinant.h
suitesparse /usr/include/umfpack_get_lunz.h
suitesparse /usr/include/umfpack_get_numeric.h
suitesparse /usr/include/umfpack_get_symbolic.h
suitesparse /usr/include/umfpack_global.h
suitesparse /usr/include/umfpack_load_numeric.h
suitesparse /usr/include/umfpack_load_symbolic.h
suitesparse /usr/include/umfpack_numeric.h
suitesparse /usr/include/umfpack_qsymbolic.h
suitesparse /usr/include/umfpack_report_control.h
suitesparse /usr/include/umfpack_report_info.h
suitesparse /usr/include/umfpack_report_matrix.h
suitesparse /usr/include/umfpack_report_numeric.h
suitesparse /usr/include/umfpack_report_perm.h
suitesparse /usr/include/umfpack_report_status.h
suitesparse /usr/include/umfpack_report_symbolic.h
suitesparse /usr/include/umfpack_report_triplet.h
suitesparse /usr/include/umfpack_report_vector.h
suitesparse /usr/include/umfpack_save_numeric.h
suitesparse /usr/include/umfpack_save_symbolic.h
suitesparse /usr/include/umfpack_scale.h
suitesparse /usr/include/umfpack_solve.h
suitesparse /usr/include/umfpack_symbolic.h
suitesparse /usr/include/umfpack_tictoc.h
suitesparse /usr/include/umfpack_timer.h
suitesparse /usr/include/umfpack_transpose.h
suitesparse /usr/include/umfpack_triplet_to_col.h
suitesparse /usr/include/umfpack_wsolve.h
suitesparse /usr/lib/
suitesparse /usr/lib/libamd.2.4.0.a
suitesparse /usr/lib/libamd.a
suitesparse /usr/lib/libbtf.1.2.0.a
suitesparse /usr/lib/libbtf.a
suitesparse /usr/lib/libcamd.2.4.0.a
suitesparse /usr/lib/libcamd.a
suitesparse /usr/lib/libccolamd.2.9.0.a
suitesparse /usr/lib/libccolamd.a
suitesparse /usr/lib/libcholmod.3.0.1.a
suitesparse /usr/lib/libcholmod.a
suitesparse /usr/lib/libcolamd.2.9.0.a
suitesparse /usr/lib/libcolamd.a
suitesparse /usr/lib/libcxsparse.3.1.3.a
suitesparse /usr/lib/libcxsparse.a
suitesparse /usr/lib/libklu.1.3.0.a
suitesparse /usr/lib/libklu.a
suitesparse /usr/lib/libldl.2.2.0.a
suitesparse /usr/lib/libldl.a
suitesparse /usr/lib/libspqr.1.3.3.a
suitesparse /usr/lib/libspqr.a
suitesparse /usr/lib/libsuitesparseconfig.4.3.1.a
suitesparse /usr/lib/libsuitesparseconfig.a
suitesparse /usr/lib/libumfpack.5.7.0.a
suitesparse /usr/lib/libumfpack.a

If I compile suitesparse myself, the same contents of the package is the result. If you would share your patches for dynamic libs, that would be great.

 Stefan Husmann <haawda>
Wed 01 Oct 2014 01:37:35 AM UTC, comment #26: 

May I ask which one is your system? I glanced on the logs you uploaded and there are errors on suitesparse cholmod detection on both. The strange thing is, it detects the headers but hit errors when linking against the libs that should be somewhere.

Did you compile suitesparse by yourself? If so, where did you place the libraries?

On my case, I patched suitesparse to generate dynamic libs and applied extra patches to octave but, may you need, I can post how I do it on openSUSE.

I track the "stable" version and, as I said, patch it a bit but octave has been working very well for me.

Regards,
André

Andre da Costa Barros <andrecbarros>
Tue 30 Sep 2014 05:23:27 PM UTC, comment #25: 

Sorry for not telling that, the message below comes without any suitesparse installed. Octave's revision number from hg repo was given below, but with 19184 I have the same issue.

with suitesparse 4.3.1 installed the build fails with the same message as in attachment #32000.


Stefan Husmann <haawda>
Tue 30 Sep 2014 02:11:30 AM UTC, comment #24: 

May you please provide the version of suitesparse library and octave are you using?

Andre da Costa Barros <andrecbarros>
Sat 27 Sep 2014 06:28:18 PM UTC, comment #23: 

In revision 19166.767103303974 I get:

In file included from ../../liboctave/array/CSparse.cc:49:0:
../../liboctave/util/oct-sparse.h:99:82: error: missing binary operator before token "("
 #if defined (SUITESPARSE_VERSION) && SUITESPARSE_VERSION >= SUITESPARSE_VER_CODE (4, 3)
                     ^

Stefan Husmann <haawda>
Mon 22 Sep 2014 01:21:18 AM UTC, comment #22: 

OK, the patch is OK, but the fragment on comment is not. Should be:

+# define SUITESPARSE_ASSIGN_FPTR2(f_name, f_var, f_assign) (SuiteSparse_config.f_name = SuiteSparse_##f_assign))

 Andre da Costa Barros <andrecbarros>
Mon 22 Sep 2014 01:17:53 AM UTC, comment #21: 

John W. Eaton, can you please substitute:
----------------------------------------------
+#if defined (SUITESPARSE_VERSION) && SUITESPARSE_VERSION >= SUITESPARSE_VER_CODE (4, 3)
+# define SUITESPARSE_ASSIGN_FPTR(f_name, f_var, f_assign) (SuiteSparse_config.f_name = f_assign)
+# define SUITESPARSE_ASSIGN_FPTR2(f_name, f_var, f_assign) (SuiteSparse_config.f_name = CHOLMOD_NAME (f_assign))
+#else
+# define SUITESPARSE_ASSIGN_FPTR(f_name, f_var, f_assign) (f_var = f_assign)
+# define SUITESPARSE_ASSIGN_FPTR2(f_name, f_var, f_assign) (f_var = CHOLMOD_NAME (f_assign))
------------------------------------------------

to
------------------------------------------------
+#if defined (SUITESPARSE_VERSION) && SUITESPARSE_VERSION >= SUITESPARSE_VER_CODE (4, 3)
+# define SUITESPARSE_ASSIGN_FPTR(f_name, f_var, f_assign) (SuiteSparse_config.f_name = f_assign)
+# define SUITESPARSE_ASSIGN_FPTR2(f_name, f_var, f_assign) (SuiteSparse_config.f_name = SuiteSparse##f_assign))
+#else
+# define SUITESPARSE_ASSIGN_FPTR(f_name, f_var, f_assign) (f_var = f_assign)
+# define SUITESPARSE_ASSIGN_FPTR2(f_name, f_var, f_assign) (f_var = CHOLMOD_NAME (f_assign))
-------------------------------------------------

See comment #15. On my last patch I changed where the modification should be made. Sorry, again. Will be more cautious next time I submit a patch.


(file #32158)

 Andre da Costa Barros <andrecbarros>
Sun 21 Sep 2014 09:13:21 PM UTC, comment #20: 

I checked in the following modified version of the patch posted here as file #32121.

http://hg.savannah.gnu.org/hgweb/octave/rev/afd6179d2616

I don't have SuiteSparse 4.3 to test but this patch works with 4.2.1.  Note that I needed to continue to use the CHOLMOD_NAME macro for 4.2.1.

John W. Eaton <jwe>
Group administrator
Wed 17 Sep 2014 02:26:47 AM UTC, comment #19: 

Is there some old version of SuiteSparse that doesn't set divcomplex and hypot to the defaults?

 Orion Poplawski <opoplawski>
Tue 16 Sep 2014 11:29:52 PM UTC, comment #18: 

One more thing, I think we should not delete the assignments because there are other people that may be linking against old versions of SuiteSparse.

I added an updated patch with the above situation on mind. (Should actually have merged with your).



(file #32121)

 Andre da Costa Barros <andrecbarros>
Tue 16 Sep 2014 10:58:17 PM UTC, comment #17: 

You are right. On this situation the function just keep calling itself. My bad, I only checked that the functions existed and had the same arguments.

Perhaps, a better approach would be to change "CHOLMOD_NAME(hypot)" to "SuiteSparse_hypot" and "CHOLMOD_NAME(divcomplex)" to "SuiteSparse_divcomplex" as the author idea of SuiteSparse seems to be allow the library user to link for optimized functions, should they exist on a particular architecture.

Andre da Costa Barros <andrecbarros>
Tue 16 Sep 2014 10:48:17 PM UTC, comment #16: 

So, I believe the setting of divcomplex and hypot was superfluous and have removed that from the patch.  Updated version attached.  Compiles and tests pass with suitesparse 4.3.1 and 4.0.2.

suitesparse 4.4.0 will introduce a cholmod_function.h header with their own macros for handling this change, but I elected to go with the current macro.

(file #32120)

 Orion Poplawski <opoplawski>
Tue 16 Sep 2014 03:58:54 PM UTC, comment #15: 

NB that I am not at all familiar with suitesparse, but I think the problem lies with these parts of the patch:

-  cm->complex_divide = CHOLMOD_NAME(divcomplex);
-  cm->hypotenuse = CHOLMOD_NAME(hypot);
+  suitesparse_assign_function(divcomplex_func, cm->complex_divide, CHOLMOD_NAME(divcomplex));
+  suitesparse_assign_function(hypot_func, cm->hypotenuse, CHOLMOD_NAME(hypot));

suitesparse_assign_function(divcomplex_func, cm->complex_divide,  CHOLMOD_NAME(divcomplex)) assigns the function pointer:

// Cope with new suitesparse versions
//
#if defined( SUITESPARSE_VERSION ) && SUITESPARSE_VERSION >= SUITESPARSE_VER_CODE(4,3)
#define suitesparse_assign_function(f_name,f_var,f_assign) (SuiteSparse_config.f_name = f_assign)
#else
#define suitesparse_assign_function(f_name,f_var,f_assign) (f_var = f_assign)
#endif

So SuiteSparse_config.divcomplex_func gets assigned to cholmod_divcomplex.  But cholmod_divcomplex does:

    return (SuiteSparse_config.divcomplex_func (ar, ai, br, bi, cr, ci)) ;

So it keeps calling itself.  Not sure if the patch or suitesparse is wrong at this point.

 Orion Poplawski <opoplawski>
Tue 16 Sep 2014 02:40:17 PM UTC, comment #14: 

I'm consistently seeing a segfault in scripts/sparse/eigs.m on 32-bit and a hang/infinite loop on 64-bit builds.  Will look further when I have time.


Orion Poplawski <opoplawski>
Tue 16 Sep 2014 02:27:30 PM UTC, comment #13: 

Humm, is a core dump generated? If so, can you upload it to some place? With only the information you provided it is hard to see what went wrong on your octave building process.

I did check eigs.m here and saw nothing wrong.

Regards,
André

Andre da Costa Barros <andrecbarros>
Mon 15 Sep 2014 07:46:51 PM UTC, comment #12: 

Of course, just as I post that my build fails in make check:

  scripts/sparse/bicgstab.m .............................. PASS    4/4  
  scripts/sparse/cgs.m ................................... PASS    3/3  
  scripts/sparse/eigs.m ..................................Makefile:2565: recipe for target 'check' failed
make[1]: Leaving directory '/builddir/build/BUILD/octave-3.8.2/test'
make[1]: * [check] Segmentation fault

 Orion Poplawski <opoplawski>
Mon 15 Sep 2014 07:45:06 PM UTC, comment #11: 

The attached patch appears to do the trick for me, thanks to Andre for all of it other than adding math.h to oct-sparse.h.

BTW - looks like suitesparse upstream may remove math.h from their include file anyway since it does not appear to be used, at which point adding it to oct-sparse.h would no longer be necessary.  Probably should make a note of that.

(file #32109)

 Orion Poplawski <opoplawski>
Mon 15 Sep 2014 02:47:59 PM UTC, comment #10: 

This approach should work.

@Orion: The header guard won't be an issue since the gnulib headers include the system headers anyways.

@John: I think it's not possible to use cmath instead of math.h here. If one includes <cmath>, the compiler is allowed to insert some built-in math definitions and ignore the contents of the file. I don't know if any compiler actually does that, though...

 Johannes Zarl <jzarl>
Sat 13 Sep 2014 07:40:09 PM UTC, comment #9: 

I think that should work.

Can we include <cmath> instead of <math.h> here?  I generally prefer to include <cmath> instead of <math.h> in C++ code unless there is some good reason to include <math.h>.

 John W. Eaton <jwe>
Group administrator
Sat 13 Sep 2014 06:56:19 PM UTC, comment #8: 

Right to both of you. What I meant was not changing the directory search order, but rather ensuring that we always include math.h before any SuiteSparse headers:


#include <math.h>
#if defined (HAVE_SUITESPARSE_AMD_H)
#include <suitesparse/amd.h>
...


That should effectively prevent it from being included inside the extern "C" block in SuiteSparse_config.h, right?

 Mike Miller <mtmiller>
Group Member
Sat 13 Sep 2014 06:26:28 PM UTC, comment #7: 

When using gnulib, I think the idea is that we should always get the gnulib version of headers before the system ones as they are supposed to be included from the gnulib headers as necessary.

 John W. Eaton <jwe>
Group administrator
Sat 13 Sep 2014 05:33:46 PM UTC, comment #6: 

Yeah, that certainly seems similar.  However, I think the problem ultimately resides with gnulib and/or octave.  It's perfectly reasonable/legal for suitesparse to include <math.h> inside of an extern "C" block, even if not strictly necessary.

However, I've sent an email to the suitesparse author and applied the suitesparse patch to the Fedora package.

Messing with include order may not help: the system math.h uses "_MATH_H" for the include guard, while gnulib uses "_GL_MATH_H".

 Orion Poplawski <opoplawski>
Sat 13 Sep 2014 12:58:39 AM UTC, comment #5: 

Can you describe the signbit issue in more detail?

I haven't tried SuiteSparse 4.3 yet, but on inspection it looks similar to our bug #43171, including a header file that is provided by gnulib inside of an extern "C" block. Is that it?

If we can't get this fixed in SuiteSparse, we might be able to work around this by ensuring that math.h is always included before any SuiteSparse header files, right?

 Mike Miller <mtmiller>
Group Member
Fri 12 Sep 2014 10:21:58 PM UTC, comment #4: 

We're running into this in Fedora Rawhide now too.  We're going to need a proper solution to the gnulib/libc signbit issue.

 Orion Poplawski <opoplawski>
Thu 11 Sep 2014 09:05:48 PM UTC, comment #3: 

There are some changes made on SuiteSparse >= 4.3 that require the octave code to be reworked. I submitted the patches at "patch #8531".

Basically, SuiteSparse now uses SuiteSparse_config variable to define the functions that handle printing, hypotenuse, complex dividing and allocation.

As explained on the patches submit, there is still a glitch that needs to be addressed. It seems to have its origins not in Octave or SuiteSparse but instead in a sort of clash between gcc and libstdc++ provided math.h include files and is triggered by mixing c++ and c code compiling. By now I am using a kludge that allows me to finish the building process by patching SuiteSparse_config.h file.

Regards to all,
André

Andre da Costa Barros <andrecbarros>
Sat 30 Aug 2014 03:09:19 PM UTC, comment #2: 

I also have problems, but different ones. Under Arch Linux, both usin gcc or clang++ results in the attached build logs. With "--without-umfpack" the build succeeds. Octave comes from hg-Tip.


(file #32000, file #32001)

 Stefan Husmann <haawda>
Sun 24 Aug 2014 07:29:10 PM UTC, comment #1: 

I'm on 4.3.1 and am also having problems, different from yours.

configure:36318: gcc -o conftest -O3 -mfpmath=sse -march=native -s -fomit-frame-pointer -pthread     conftest.c -lamd -lm   >&5
usr/local/lib/libamd.so: undefined reference to `SuiteSparse_config'
usr/local/lib/libamd.so: undefined reference to `SuiteSparse_free'
usr/local/lib/libamd.so: undefined reference to `SuiteSparse_malloc'
collect2: error: ld returned 1 exit status

I've tried specifying the include directory with CPPFLAGS="-I/usr/local/include" but it doesn't fix it.

 Ceral Paquet <octavebugs>
Sun 24 Aug 2014 06:20:37 AM UTC, original submission:  

Suitesperse 4.3.x has changed interface


/pub/devel/octave/octave-3.8.2-1.x86_64/src/octave-3.8.2/liboctave/array/CSparse.cc:5667:19: error: 'cholmod_common' has no member named 'print_function'
               cm->print_function = 0;
                   ^
/pub/devel/octave/octave-3.8.2-1.x86_64/src/octave-3.8.2/liboctave/array/CSparse.cc:5672:19: error: 'cholmod_common' has no member named 'print_function'
               cm->print_function =&SparseCholPrint;
                   ^
/pub/devel/octave/octave-3.8.2-1.x86_64/src/octave-3.8.2/liboctave/array/CSparse.cc:5676:15: error: 'cholmod_common' has no member named 'complex_divide'
           cm->complex_divide = CHOLMOD_NAME(divcomplex);
               ^
/pub/devel/octave/octave-3.8.2-1.x86_64/src/octave-3.8.2/liboctave/array/CSparse.cc:5677:15: error: 'cholmod_common' has no member named 'hypotenuse'
           cm->hypotenuse = CHOLMOD_NAME(hypot);


 $ grep -rH print_func
Include/cholmod_core.h:    /* CHOLMOD print_function replaced with SuiteSparse_config.print_func */

marco atzeri <matzeri>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #32969:  SuiteSparse-4.4.1-patches.tar.gz added by alge (16KiB - application/x-gzip)
file #32792:  suitesparse-sharedlibs.patch added by haawda (63KiB - text/x-patch)
file #32218:  suitesparse-patches.tar.gz added by andrecbarros (11KiB - application/gzip)
file #32219:  octave-suitesparse.tar.gz added by andrecbarros (4KiB - application/gzip)
file #32158:  octave-suitesparse-ge-4.3.patch added by andrecbarros (10KiB - application/x-download)
file #32121:  octave-suitesparse-ge-4.3.patch added by andrecbarros (10KiB - application/x-download)
file #32120:  octave-suitesparse.patch added by opoplawski (11KiB - text/x-patch - Updated suitesparse patch)
file #32109:  octave-suitesparse.patch added by opoplawski (12KiB - text/x-patch)
file #32001:  makepkg_octave-hg_clang++.txt added by haawda (508KiB - text/plain)
file #32000:  makepkg_octave-hg_g++.txt added by haawda (500KiB - text/plain)

 

Carbon-Copy List
  • -email is unavailable- added by svillemot (Posted a comment)
  • -email is unavailable- added by svillemot
  • -email is unavailable- added by alge (Updated the item)
  • -email is unavailable- added by calaba (Posted a comment)
  • -email is unavailable- added by jzarl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by opoplawski (Posted a comment)
  • -email is unavailable- added by andrecbarros (Posted a comment)
  • -email is unavailable- added by haawda (Updated the item)
  • -email is unavailable- added by octavebugs (Posted a comment)
  • -email is unavailable- added by matzeri (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 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-17 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed
    2015-02-14 mtmiller Assigned toNone mtmiller
    2015-02-03 svillemot Carbon-Copy- Added svillemot
    2015-02-01 alge Attached File- Added SuiteSparse-4.4.1-patches.tar.gz, #32969
    2015-01-08 haawda Attached File- Added suitesparse-sharedlibs.patch, #32792
    2014-10-03 andrecbarros Attached File- Added suitesparse-patches.tar.gz, #32218
        Attached File- Added octave-suitesparse.tar.gz, #32219
    2014-09-22 andrecbarros Attached File- Added octave-suitesparse-ge-4.3.patch, #32158
    2014-09-16 andrecbarros Attached File- Added octave-suitesparse-ge-4.3.patch, #32121
    2014-09-16 opoplawski Attached File- Added octave-suitesparse.patch, #32120
    2014-09-15 opoplawski Attached File- Added octave-suitesparse.patch, #32109
    2014-09-15 mtmiller Dependencies- bugs #43220 is dependent
    2014-09-13 mtmiller Dependencies- patch #8531 is dependent
    2014-08-30 haawda Attached File- Added makepkg_octave-hg_g++.txt, #32000
        Attached File- Added makepkg_octave-hg_clang++.txt, #32001
    2014-08-24 rik5 Carbon-CopyRemoved 72865 -
    2014-08-24 rik5 SummarySuitesparse 4.3.x Suitesparse 4.3.x has changed APIs, no longer builds with Octave

    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