Installation error

264 views
Skip to first unread message

Alessio Castrica

unread,
Aug 26, 2022, 2:35:39 AM8/26/22
to CVXOPT
Hi, 
I'm trying to install cvxopt v1.2.5 on a docker container and encountered this error when running docker build:
Running setup.py install for cvxopt did not run successfully.

....
/usr/bin/ld: cannot find -llapack
/usr/bin/ld: cannot find -lblas

Please see the screenshot for the full error. 
I also attached my dependencies. 
I initially tried with the latest version but then tried with v1.2.5 after reading this thread https://stackoverflow.com/questions/65967466/python-package-not-installable-in-docker-container 

Could someone please let me know if there's a solution or a viable workaround?

Any help would be greatly appreciated. Thanks in advance

Screenshot 2022-08-25 at 18.47.13.png
requirements.txt

Martin

unread,
Aug 26, 2022, 2:58:16 AM8/26/22
to CVXOPT
You need to install LAPACK and BLAS. This should work in Ubuntu:

apt-get -y install python-dev python-pip libopenblas-dev libsuitesparse-dev libgsl0-dev libfftw3-dev libglpk-dev libdsdp-dev  
pip install cvxopt

Alessio Castrica

unread,
Aug 28, 2022, 8:40:59 AM8/28/22
to CVXOPT
Hi Martin, 
thanks for answering. 
I installed LAPACK and BLAS, but I still get a similar error (this time without cannot find -llapack, -lblas).
Dockerfile
Screenshot 2022-08-26 at 11.49.23.png

Martin

unread,
Aug 28, 2022, 8:55:41 AM8/28/22
to CVXOPT
Try changing 1.2.5 to 1.3.0 in your requirements file. As far as I recall, CVXOPT 1.2.5 is not compatible with Python 3.10, but the most recent version is.

Alessio Castrica

unread,
Sep 6, 2022, 12:26:23 AM9/6/22
to CVXOPT
Screenshot 2022-09-04 at 12.36.39.png
Still getting the same errror with python 3.10 and cvxopt 1.3.0

Filipe Oliveira

unread,
Apr 19, 2023, 5:24:13 PM4/19/23
to CVXOPT
Hello!

Sorry for ressurrecting this post but I couldn't find any other reference to this problem.
I've joined the group to tell you that this is related to the default `linux/arm64` image architecture that Docker on M1 (an ARM processor) chooses when pulling a image to run, that can be checked when `docker inspect`ing the image:
Screenshot 2023-04-17 at 17.58.39.png
I had the same problem these days:
Screenshot 2023-04-17 at 17.56.09.png
You can also note that by checking the package types that are being installed `*-aarch64-*`.

The only way of finish the installation was to install additional packages in OS and to bring SuiteSparse source code before installing it (in the dockerfile):
Screenshot 2023-04-17 at 18.00.32.png
But, even after finishing the installation successfully, my application failed due the lack of `GPLK_MI` solver (not sure if it's under this group's sceop as it fails under `cvxpy` package):
image (4).png

The only way to make it work was to specify a `linux/amd64` architecture for the base image when pulling it via `--platform linux/amd64` (that has serious performance problems under M1 due to emulation needs). In this case, I believe it doesn't need any compilation and finishes the installation seamlessly:
Screenshot 2023-04-17 at 18.09.40.png
Screenshot 2023-04-17 at 18.10.26.png

Filipe Oliveira

unread,
Apr 19, 2023, 5:24:13 PM4/19/23
to CVXOPT
Hello!

Sorry for ressurrecting this.
Just to inform, I've discovered this problem is related to the default linux/arm64 image architecture that Docker on Desktop for Macbooks using M1 processor (uses ARM architecture) choose when pulling an image. Without defining a --platform linux/amd64, it always choose an ARM flavor.
When running under and ARM flavor, pip install cvxopt needs to compile some stuff under the hood, which brings the necessity of installing additional packages and bringing SparseSuite source code to complete the installation:
Screenshot 2023-04-17 at 18.00.32.png
Even when doing the above steps, my application fails when running, due to the lack of a GPLK_MI solver under cvxpy (I'm not sure if this problem is under the scope of this group):
image (4).png

The only solution I know for this problem is to choose the linux/amd64 architecture when pulling the image to run. It does not demand any compilation under the hood, but it has a big performance issue under M1, as it runs under emulation of QEMU:
Screenshot 2023-04-17 at 18.09.40.png

On Tuesday, September 6, 2022 at 1:26:23 AM UTC-3 Alessio Castrica wrote:
Reply all
Reply to author
Forward
0 new messages