In order to run an optimization problem we set up Gurobi 6.0.4 together with
Anaconda (Version 2.2.0) Python (Python 2.7.9.) on
Linux CentOS release 6.6 (Final) with the 2.6.32-504.16.2.el6.x86_64 Kernel
Following the installation guidelines of Gurobi (listed here: http://www.gurobi.com/documentation/6.0/quickstart_linux.pdf)
everything worked out in the first step. Gurobi was installed, could obtain a license. Also the PATH variables have been set (in the .bashrc) according to the manual, with a little extension for the referal to anaconda python (and not the other local Versions of python (being 2.7 and 3.4):
export GUROBI_HOME="/opt/gurobi604/linux64"
export PATH="${PATH}:${GUROBI_HOME}/bin:${PATH}:opt/anaconda/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"
Following the procedure we executed: python2.7 setup.py install in the respective directory /opt/gurobi604/linux64. After this usually you could run the import gurobipy command in the python interpreter wihtout errors. For older Versions of Gurobi (as 5.6.3) this works out very well.
For 6.0.4 though we constantly receive the error:
ImportError: /opt/anaconda/lib/python2.7/site-packages/gurobipy/gurobipy.so: undefined symbol: _Py_FalseStruct
This is very reproducible, no matter if we put anaconda also in the global path, and check the bash for any overwriting of the environment variables, which is not the case.
On Windows 8 the Gurobi 6.0.4 and Anaconda Python 2.2.0 work together without any problems.
Also applying hints from here: Python Module Error on Linux did not work out.
Did anyone else experience these problems with this tooling combination? thx.
The error message indicates that you use the Python module for version 3.4 in your Python 2.7 package directory. This can happen if you do not clean your Python module build directory between builds. Please try the following:
Completely remove the 2.7 package from your Python 2.7 installation (e.g. remove /opt/anaconda/lib/python2.7/site-packages/gurobipy)
Completely remove the Python module build directory from your Gurobi installation (e.g. /opt/gurobi604/linux64/build)
Re-run the build process for the Python 2.7 module (e.g. run "python2 setup.py install" in /opt/gurobi604/linux64)
Please note that CentOS is currently a non-supported platform for Gurobi.
Thank you for the hint, I think we tried that, but did not finish the procedure in this way. We tried to clean the system but in that particular case still hat both python Versions (due to other applications that use 3.4) on the machine. Our solution in this case was just to reinstall everything clean on a Ubuntu 14.04 VM. Since then no further problems occured. (I know not the cleanest solution.)
We had some similar issues when we updated to Gurobi 6.5, but that could be solved when corrctly addressing the usual path issues.
Thank you in any case for the reply, I think this really will help us with the next, then clean deployment :-)
Related
I have a production server with Ubuntu 20.04 and Python v3.8.10.
My development environment is Ubuntu 22.04 with Python v3.10.6.
Both environments make use of a virtual environment when running python code.
Thus far the differences between Python 3.8 and 3.10 have not necessitated that I match my environments exactly. However, I am now forced to use a poorly maintained Python library in my code (provided by a payment gateway), and I encountered version-specific bugs with the library immediately after installing it. Needless to say, I am not confident that if I get it working in the development environment, it will work in the production environment as well. I need to be sure it works in production the first time.
I believe I have managed to successfully install Python 3.8 from source on my development system (without uninstalling Python 3.10). I managed to set up the virtualenv with the older version of Python successfully as well. The installation of requirements, however, fails with /usr/bin/ld: cannot find -lboost_python: No such file or directory during the installation of the pgmagick package. My understanding of the error is that I am missing the libboost_python-dev package for Python v3.8.
How can I install the older libboost_python-dev package on ubuntu 22.04?
I'm trying to set up a conda environment with python 3.6 on a remote server working on CentOS. The installation goes well, but once I try to execute python I get the following message python: /lib64/libc.so.6: version 'GLIBC_2.15' not found. I noticed that for other python version older than 3.4 this doesn't happen.
Given this, I tried installing glibc before python, but after installing python 3.6 and trying to run it, now I get Segmentation fault (core dumped).
Note that I don't have permissions to update conda and that the version the server is using is 4.4.7, so I haven't tried updating it. However, I had previously set an environment without any problem. After I tried to install a package my jupyter notebooks wouldn't work so I removed the environment.
What would be the new system and the old one.
The old system -- the remove server running CentOS, has GLIBC that is older than 2.15.
The new system -- the one on which your Python 3.6 was compiled, used GLIBC-2.15 (or newer).
You need to either find a Python 3.6 build which is targeted to your version of CentOS, or you need to compile one yourself on a system with GLIBC matching whatever is installed on your remote server.
P.S. Saying "server running CentOS" is like saying "system running Windows" (i.e. not saying much). Which version of CentOS?
when I try to check python version in Centos7 by typing command
1) python --version
-bash: /usr/local/bin/python3.6: No such file or directory
OR
2) which python
"alias python='/usr/local/bin/python3.6'.
Could anyone explain me why it shows like this instead of showing python version?
Thanks.
In order to sum up, for future people who will look in this question:
when installing different versions of python on linux using package manager (in this case yum because you are using CentOS, but it might be apt or something else) linux installs the side-by-side, meaning you have all of the versions installed together.
If you want to use a specific version other than your linux distribution diffault one you need to call it explicitly (i.e. python3.6 or python3.8)
Make sure you are looking for the wanted python version on the right path.
When you want to run some version of python after installing it I suggest you to just write python in the bash and just hit tab+tab and the bash will suggest all the installed versions in the $PATH.
I need to run a program which use VTK5 on my Archlinux PC, but I found it really hard to install VTK5, there is only VTK6(not compatible with VTK5) in official repo, and when I try to install it from AUR, it returns "Makepg was unable to build vtk5", then I try to install through source code, the result is that I was unable to install the VTK Python module...
Is there anybody who has any experience or idea about it?
I have not installed on Archlinux specifically, but on different linux machines. If you compile from source and are interested in python, remember to select the option python wrapping when running cmake. Btw, once built, you will have to update both the pythonpath and the ldlibrarypath.
You can also have a try at enthought canopy, which distributes a complete installation with numpy, scipy, vtk http://docs.enthought.com/canopy/quick-start/install_linux.html
When I try to install PyFITS I get the following error
python version 3.3 is needed, which was not found in registry
But I do have python 3.3 installed as well as numpy and Scipy. I would appreciate any help sorting this out. Thanks
OS---Windows 7 64bit
Python----3.3.2
This problem is actually addressed in the latest Astropy installation troubleshooting docs: http://docs.astropy.org/en/v0.2.4/install.html#the-windows-installer-can-t-find-python-in-the-registry
This issue is not unique to PyFITS, and has to do with whether or not the installation executable was built with UAC support, as well as whether your Python installation was installed "For all users" or "For the current user", as that affects which registry hierarchy Python installs its relevant keys into.
The script linked to in that documentation should fix up your registry with the correct entries so that the correct Python installation can be found regardless of how it was installed. But as with anything that messes with the registry please do handle with care.