upgrade cvxopt to version 1.1.8

[dimpase]

this is the current stable version

The tarball is here: ​http://users.ox.ac.uk/~coml0531/sage/cvxopt-1.1.8.tar.gz

I removed html docs from the source (​https://github.com/cvxopt/cvxopt/archive/1.1.8.tar.gz) to make it smaller.

[dimpase]

New commits:

​c040534

update to 1.1.8

[fbissey]

Looks good to me. No doctest broken on linux x86_64.

[vbraun]

On older linux (Ubuntu 12.04) I get

ImportError: /mnt/highperf/buildbot/slave/sage_git/build/local/lib/python2.7/site-packages/cvxopt/amd.so: undefined symbol: clock_gettime

according to man page, needs to "link with -lrt (only for glibc versions before 2.17)" but does not.

[fbissey]

Upstream probably doesn't build on older machines. Should be trivial to fix.

[dimpase]

Replying to vbraun:

On older linux (Ubuntu 12.04) I get

ImportError: /mnt/highperf/buildbot/slave/sage_git/build/local/lib/python2.7/site-packages/cvxopt/amd.so: undefined symbol: clock_gettime

according to man page, needs to "link with -lrt (only for glibc versions before 2.17)" but does not.

It does not seem that testing glibc version tells you the right thing. Indeed, on Ubuntu 14.04, where this all works, I see

>>> import platform
>>> platform.libc_ver() 
('glibc', '2.4')

And I don't even have librt. I will just add it unconditionally, for every Linux...

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​8c1e90d	update to 1.1.8
​6390e86	add 'rt' to libs on linux

[fbissey]

Wrong solution

if SUITESPARSE_EXT_LIB:
    amd = Extension('amd',
        libraries = ['amd','suitesparseconfig'],
        include_dirs = [SUITESPARSE_INC_DIR],
        library_dirs = [SUITESPARSE_LIB_DIR],
        sources = ['src/C/amd.c'])
else:
    amd = Extension('amd', 
        include_dirs = [ 'src/C/SuiteSparse/AMD/Include', 
            'src/C/SuiteSparse/SuiteSparse_config' ],
        define_macros = MACROS,
        sources = [ 'src/C/amd.c', 'src/C/SuiteSparse/SuiteSparse_config/SuiteSparse_config.c'] +
        glob('src/C/SuiteSparse/AMD/Source/*.c') )

The amd extension doesn't use libraries so I would be surprised if it worked by adding it to BLAS_LIBS.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​fdaeefa

add libs='rt' to amd ext.

[dimpase]

right, it should have gone to the amd Extension chunk, sorry. The patch is longer, as I fixed all the fizz, by cloning ​https://github.com/cvxopt/cvxopt and making a new patch using the old one. Then I just added libraries=['rt'] unconditionally there -- should this be done for Linux only?

[fbissey]

No librt on OS X as far as I can tell, I don't know about cygwin. I would restrict it.

[fbissey]

clock_gettime is not in the AMD code it is in the SuiteSparse_config I am checking the implications.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​4b91b98

add libs='rt' to amd ext (on linux only)

[dimpase]

Replying to fbissey:

clock_gettime is not in the AMD code it is in the SuiteSparse_config I am checking the implications.

well, the import error is in amd.so, and src/C/SuiteSparse/SuiteSparse_config/SuiteSparse_config.c gets complied into the amd extension. So this looks right what I do now...

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​e8c1e0a

add libs='rt' to amd ext (on linux only)

[fbissey]

Volker reported one failure, there may be other hidden behind the first one. That file is also included in cholmod and umfpack so they are potentially affected too. However the code should only be enabled if SUITESPARSE_TIMER_ENABLED is defined, in turn it depends on whether NTIMER is defined (which it is for cholmod and umfpack so in the end they won't be affected). A better solution in my opinion is to add [('NTIMER', '1')] to the line define_macros for the amd section.

---

New commits:

​e8c1e0a

add libs='rt' to amd ext (on linux only)

[dimpase]

adding things like [('NTIMER', '1')] looks like going too far, as you're changing the behaviour of upstream code this way...

[fbissey]

I don't think cvxopt cares about timing of the code, in fact SuiteSparse_{tic,toc,time} are used nowhere in AMD's code. It is only enabled as part of SuiteSparse_config.c by accident I would argue. In contrast cholmod and umfpack have code that can use SuiteSparse_time and it is disabled on purpose in those. Those function are only used to measure performance, I don't think cvxopt would be doing it that way, if it was interested in measuring the performance of the SuiteSparse code.

[fbissey]

I would further argue that we should point to upstream that unless they want to use those timing functions in the future, NTIMER should be in the default macros variable that is currently empty.

[dimpase]

I just asked upstream ​here on this.

[fbissey]

OK, I'll add an argument: SuiteSparse_config.c is not part of amd's sources. If you were using an external suitesparse install, you would have a suitesparse_config library and amd would get the functions from this library as needed. But here we have a custom system that makes SuiteSparse_config.c a part of the used amd source code and including all the function of SuiteSparse_config.c instead of just the one needed by amd. That include the timing functions.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​79784f3

fix building amd ext

[dimpase]

indeed, that was the right suggestion for the fix. The upstream fixed this in dev ​here 3 weeks ago...

please see the latest commit update.

---

New commits:

​79784f3

fix building amd ext

[fbissey]

I am happy with that resolution. Back to positive review.