FindPythonLibs.cmake is somehow finding Python versions that don't exist/were uninstalled.
When I run find_package(PythonLibs 3 REQUIRED) CMake properly finds my Python3.6 installation and adds its include path, but then I get the error
No rule to make target 'C:/Users/ultim/Anaconda2/libs/python27.lib', needed by 'minotaur-cpp.exe'. Stop.
This directory doesn't exist, and I recently uninstalled Anaconda and the python that came with it. I've looked through my environment variables and registry, but find no reference to this location.
Would anyone know where there might still be a reference to this location?
Since the "REQUIRED" option to find_package() is not working, you can be explicit about which Python library using CMake options with cache variables:
cmake -DPYTHON_INCLUDE_DIR=C:\Python36\include -DPYTHON_LIBRARY=C:\Python36\libs\python36.lib ..
Related
I've been trying to install this ATLAS tool on my windows computer. The instructions are very simple and straight forward:
clone the ATLAS git repository: $ git clone https://gitlab.inria.fr/alta/alta.git
I should have all the mandatory dependencies installed:
-the SCons build system;
-a C++11 compiler, such as recent versions of GCC or Clang;
-Eigen >= 3.0 (libeigen3-dev package on Debian and derivatives; libeigen3 in MacPorts; eigen in Brew.)
Essentially, after I have those installed, I can run scons on python and it should check to see whether the required dependencies are met, and then all compilation byproducts will go to the sources/build like the instructions says. The problem is after running the scons command, I get the following response:
scons: Reading SConscript files ...
<<INFO>> Using config file "./configs/scons/config-windows-cl.py"
the current platform is: win32
Checking for C++ library dl... no
Checking for C++ library rt... no
Checking whether 'c++11' is supported... yes
Checking for eigen3 using pkg-config... no
Checking for C++ header file Eigen/Core... no
obtaining Eigen v3.2.7
error: downloaded file 'eigen-3.2.7.tar.gz' is inauthentic
error: got sha256 hash ea25f177c8716e7daa618533e116706d97e25c9912e016009d8a9264e39cad57 but expected 5a50a006f83480a31f1f9beabec9e91dad95138df19363ee73ccf57676f10405
eigen-3.2.7.tar.gz: downloaded file is inauthentic
The compilation process results in a eigen-3.2.7.tar.gz file with a WRONG-HASH File type. Moreover, when I open the file, it reads, "Repository eigen/eigen not found".
What does it mean that the eigen-3.2.7.tar.gz file is inauthentic and why does it have a WRONG-HASH File type? My guess is that my machine is complaining that the eigen repository is not downloaded, but I thought I installed everything correctly.
Here how I went about installing the dependencies:
Scons
I installed Scons build system by simply typing the following command in my anaconda python environment: conda install -c conda-forge scons
C++ complier
This was actually already installed on my computer a while back ago. I can't exactly remember how it was installed, but my machine seems to recognize it on the checklist so no need to worry about that.
Eigen
To install this dependency I just simply cloned the repository from here in GitHub. The Eigen folder is find inside the alta directory(the highest level directory.
I new to this, so it could be very possible that my steps to install these dependencies were not correct. Should I set some sort of environment path? I'm wondering if I installed my eigen repository correctly. To be honest, i'm not exactly sure why the build process fail, thus the issue may be something totally different then how I installed my dependencies. However, at this point I am lost and in need of further instruction or intuition.
The link to the installation page is here . As you can see its not many instruction and they are quite simple, which makes this whole thing even more frustrating.
It doesn't sound like there's a lot wrong here... for Windows, the results look normal: libdl and librt are linux-y things. And Windows platforms also don't have the pkg-config way of getting information about building with a library, so those configure results are nothing to worry about. It just sounds like the fetcher tool isn't resilient to the thing it needs to fetch already being there. You want to look at the external area as to why it's deciding to, and then unhappy with, fetching something that's already in place. Maybe you weren't supposed to git clone that piece in the first place? The instructions you point to hint not: "If Eigen could not be found, it is automatically downloaded from upstream."
As to your problem of not finding a build subdirectory, your guess is correct: scons is basically two-pass, the first pass being to read the config files and build up the dependency tree, the second being to do any required builds. Dependency fetching must be done in the first pass in this project (there are ways to code such an animal to be a build-time thing, but that's harder so most projects don't), so once the dep checking failed, it never went on the the build phase, thus the build directory was never created.
I think you need to remove your eigen download.
According to: http://alta.gforge.inria.fr/install.html
If Eigen could not be found, it is automatically downloaded from upstream.
The downloaded file is integrity-checked, and then the software is built and
installed under the external/build sub-directory of the source tree.
I've just upgraded to OSX Yosemite. I'm running brew doctor and among the zillions of warnings it generates is:
Warning: /usr/local/share/python is not needed in PATH.
Formerly homebrew put Python scripts you installed via `pip` or `pip3`
(or `easy_install`) into that directory above but now it can be removed
from your PATH variable.
Python scripts will now install into /usr/local/bin.
You can delete anything, except 'Extras', from the /usr/local/share/python
(and /usr/local/share/python3) dir and install affected Python packages
anew with `pip install --upgrade`.
I've looked carefully everywhere, and I can't find what is adding /usr/local/share/python to my path. My .bash_profile contains no mention of python. /private/etc/paths.d contains only a file called "git". I did find an instance of /usr/local/share/python in /private/etc/paths, but I deleted that, but when I start a new terminal after that and rerun brew doctor I still get the warning. Can anyone suggest how I can stop this? It's driving me insane!
Im not able to comment, and while I don't have an answer, this might help through process of elimination, or potentially help your future problem solver.
What about etc/profile; any sign in that file?
Do you have a ~/.profile it could be in?
What do you get when you: echo $PATH, any sign of said path?
What about export, or declare (with no options)?
How are you setting/exporting your desired path now?
Probably not what you want to hear, but I always do a fresh install rather than upgrade for fear of issues like this. Doing so would most likely solve your issues; all zillion of them. I know I haven't had any issues, or even a single warning from Homebrew, since I moved to Yosemite.
I am planning to use Metis for drawing some networks and graphs using Python. I downloaded Metis from here. For installing the Python wrapper, I followed the instructions given here, but when I run the easy_install command like:
$ easy_install metis
I get this error:
RuntimeError: Could not locate METIS dll. Please set the METIS_DLL environment variable to its full path.
From the second link above, I understand that I have to specify the full path to some 'METIS shared library' file in the METIS_DLL environment variable. But I don't know what the file is called and where it is located or how I should specify the path in an environment variable.
According to my research on Google, I found out that the file might be called 'libmetis.so' but I don't have any file of that name. Could someone give me a clue on this?
Any help would be appreciated, thanks.
I assume that you are working on Linux (because of the .so suffix) and that you have downloaded, compiled and installed the source code linked in the page. User libraries are installed in /usr/lib or /usr/local/lib and their subdirectories. Note that you might have lib64 or lib32 also, so try searching there. Try also in /opt and in the site-packages Python external modules folder, although it's usually placed inside /usr/lib. Entering locate libmetis.so at the command line might help.
If you have downloaded that package and not compiled yet, then you simply don't have that file. Read BUILD.txt or BUILD-windows.txt and follow the instructions.
Please note that this question belongs on Superuser rather than on Stackoverflow.
I have 2 versions of python installed, but cmake is using older version. How do I force cmake to use the newer version?
You may try either of these depending on what you need:
For CMake >= 3.12
According to the changelog:
New "FindPython3" and "FindPython2" modules, as well as a new
"FindPython" module, have been added to provide a new way to locate
python environments.
find_package(Python COMPONENTS Interpreter Development)
Docs:
This module looks preferably for version 3 of Python. If not found,
version 2 is searched. To manage concurrent versions 3 and 2 of
Python, use FindPython3 and FindPython2 modules rather than this one.
For CMake < 3.12
Docs:
find_package(PythonInterp 2.7 REQUIRED)
find_package(PythonLibs 2.7 REQUIRED)
Try to add -DPYTHON_EXECUTABLE:FILEPATH=/path/to/python2.7
It might be a path problem?
Also could specify the path to your python library,use your version that you want:
cmake -DPYTHON_LIBRARIES=/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib .
I had a similar problem, and resolved it using Paul's answer as a hint. I needed to use python2.7 to compile an older library, but cmake keeps picking up my python3.2 libraries (and executable).
First, I ran cmake with default options, then edited the CMakeCache.txt file which it generated. I did it this way primarily because I didn't know the proper -D... incantations to cause cmake to get the python library and include paths, etc right in the first place.
In my CmakeCache.txt, I found lines like this
Path to a program
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python
Path to a directory
PYTHON_INCLUDE_DIR:PATH=/usr/include/python3.2
Path to a library
PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython3.2.so
And replaced every occurrence of python3.2 with python2.7. I also had to rename the PYTHON_EXECUTABLE to use python2.7, since python is a symlink to python3.2 on my system.
Then I reran cmake. Because it prefers its cached values to actually looking for the libraries, this should work in all cases. At least, it did in mine.
I use anaconda(python 2.7.8) as well as python 2.7.6.
I tried -DPYTHON_EXECUTABLE:FILEPATH=$ANACONDA_HOME/bin, but version 1.4 found (weird:).
My solution is changing it to PYTHON_EXECUTABLE:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -DBUILD_TIFF=ON \
-DPYTHON_LIBRARY=$ANACONDA_HOME/lib/libpython2.7.so \
-DPYTHON_INCLUDE_DIR=$ANACONDA_HOME/include/python2.7/ \
-DPYTHON_EXECUTABLE=$ANACONDA_HOME/bin/python
My use case was a rather large project in which C++ classes were made available to Python scripts via Boost.Python. After having fought the various quirks of CMake's Python interpreter and library detection, I finally gave up and rolled my own. My approach is based on a slightly after-edited version of the python-config script that is sometimes (but not always!) put into a newly created virtual environment (see this SO post on pyvenv for these issues, but I digress). This script is invoked by a small CMake snippet pyconfig.cmake. Both are freely available from the GitHub repo cmake-python-config.
Warning: The scripts assume that you have a Python 3 interpreter in your PATH. Detection of Python 2 is not attempted. The scripts do not attempt to find all installed versions of Python3 either.
I'm currently doing some embedded systems programming. This was set up by somebody else a few years ago. So now I'm looking to upgrade to Python 2.7.2 to make things simpler because I have already run into two cases where what I coded wasn't supported.
What is currently running:
: uname -a
Linux host1 2.6.18-6-486 #1 Sun Feb 10 22:06:33 UTC 2008 i586 GNU/Linux
: python -v
Python 2.4.4
: pyversions -i
python2.4
So right now only 2.4 is installed.
I untarred python2.7.2 and when I go to that directory and run python27 setup.py install --home=/home/jhemilian and it seems like python2.4 doesn't seem to know the with...as statement syntax:
host1:/home/jhemilian/src/Python-2.7.2: python setup.py install --home=/home/jhe
milian
File "setup.py", line 361
with open(tmpfile) as fp:
^
SyntaxError: invalid syntax
Before I go figuring this out I first have a question: python itself is being used to install Python? What if I didn't have the first version of Python installed? I know it's shipped with most Linux but hypothetically -- how does such a seeming catch-22 like that work?
What I am looking to do is install python2.7 in a benign location, keeping the python command still as using Python 2.4 just in case the "legacy" software i'm running is dependent on it, and running python2.7 myscript.py et cetera when I want to run one of my newer scripts. Feel free to comment if there is a cleaner or more practical (or even safer!) way to do this.
I don't think it would make much sense to go replacing all the with statements with compatible try blocks. I've looked though the READMEs and online documentation but I can't seem to find a way to install Python without already having Python. Note that I DO NOT have internet connection, although if desirable or necessary I could. It would be great if somebody could point me in the right direction. Thanks!!
It's all right in the README...
You don't need to use python to install, in fact, you shouldn't...just:
./configure
make
make install
If you want to install in a specific dir, just follow what the README says:
Installing
To install the Python binary, library modules, shared library modules
(see below), include files, configuration files, and the manual page,
just type
make install
This will install all platform-independent files in subdirectories of
the directory given with the --prefix option to configure or to the
prefix' Make variable (default /usr/local). All binary and other
platform-specific files will be installed in subdirectories if the
directory given by --exec-prefix or theexec_prefix' Make variable
(defaults to the --prefix directory) is given.
If DESTDIR is set, it will be taken as the root directory of the
installation, and files will be installed into $(DESTDIR)$(prefix),
$(DESTDIR)$(exec_prefix), etc.
All subdirectories created will have Python's version number in their
name, e.g. the library modules are installed in
"/usr/local/lib/python/" by default, where is the
. release number (e.g. "2.1"). The Python binary is
installed as "python" and a hard link named "python" is
created. The only file not installed with a version number in its
name is the manual page, installed as "/usr/local/man/man1/python.1"
by default.
If you want to install multiple versions of Python see the section
below entitled "Installing multiple versions".
The only thing you may have to install manually is the Python mode for
Emacs found in Misc/python-mode.el. (But then again, more recent
versions of Emacs may already have it.) Follow the instructions that
came with Emacs for installation of site-specific files.
EDIT: virtualenv is apparently for already-installed Python versions. Disregard this recommendation.
I think what you want is virtualenv.
I haven't used it myself, but I understand this is what it's meant for.
From the website:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
EDIT: Upon review, I think you want Alberto's answer, so I voted him up for visibility.