I am trying to compile Python 2.6.7 with a custom module built in but I am running into problems. Everything is going fine until the linker tries to link the dependencies that my module has. The make file gets generated just fine and the path were the libraries are installed to is correct. The way I configured Python to compile with my custom module is like so:
_myplugin _myplugin.c++ -I/home/me/Desktop/Depends/include -L/home/me/Desktop/Depends/lib -l libcrvs_pic.a -l libsb_pic.a -l liblmgr_dongle_stup_pic.a
The build fails on this line:
/usr/bin/ld: cannot find -llibcrvs_pic.a
Any help would be much appreciated!
I think what you need to do is specify the libraries without the lib prefix, and also without the .a suffix.
Like so:
-lcrvs_pic
Related
I have a C++ application (X-Plane) for which there is a plugin which permits the use of python scripts (XPPython3 plugin). The plugin is written in C, using python CAPI, and works great, allowing me to write python scripts which get executed within the C++ application.
On Windows 10, I want to extend my python features by importing imgui. I have a python cython-built pyd file (_imgui.cp39-win_amd64.pyd).
If I place the pyd file in C\Program Files\Python39\DLLs, it works as expected: C++ application calls CAPI to python, which loads script which imports and executes imgui code.
If I place the pyd file anywhere else, embedded python either reports "module not found" -- if the pyd isn't on sys.path(), or if it is on sys.path():
ImportError: DLL load failed while importing _imgui: The parameter is incorrect.'
Changes using: os.add_dll_directory(r'D:\somewhere\else')
Does not effect whether the module is found or not, nor does it change the 'parameter incorrect' error. (see https://bugs.python.org/issue36085 for details on this change. -- my guess is add_dll_directory changes lookup for DLLs, but not for pyd?) sys.path appears to be used for locating pyd.
Yes, the pyd is compiled with python3.9: I've compiled it both with mingw and with visual studio toolchains, in case that might be a difference.
For fun, I moved python-standard _zoneinfo.pyd from Python39\DLLs and it fails in the same way in embedded python: "The parameter is incorrect". So, that would appear to rule out my specific pyd file.
The key question is/are:
Other than placing a pyd file under PythonXX\DLLs, is there a way to load a PYD in an embedded python implementation? (I want to avoid having to tell users to move my pyd file into the Python39\DLLs directory... because they'll forget.)
Note that using IDLE or python.exe, I can load pyds without error -- anywhere on sys.path -- so they don't have to be under Python39\DLLs. It's only when trying to load from embedded python that the "Parameter is incorrect" appears. And of course, this works flawlessly on Mac.
(Bonus question: what parameter? It appears to be python passing through a windows error.)
There seems to be a simple answer, though I suspect it's better characterized as a python bug.
There is nothing magical about Python39\DLLs directory.
The problem is using absolute vs relative paths in sys.path.
Python can find modules using absolute or relative paths. So if zippy.py is in folder foobar,
sys.path.append('foobar')
import zippy
# Success
Python and find, BUT NOT LOAD pyd files using relative paths. For example, move _zoneinfo.pyd from PythonXX\LDDs to foobar
sys.path.append('foobar')
import _zoneinfo
# ImportError: DLL load failed while importing _zoneinfo: The parameter is incorrect.'
Instead, use absolute path, and it will find and load PYD:
sys.path.append(r'c:\MyTest\foobar')
import _zoneinfo
# Success
So, there is actually a way to do this—that is, ship your application with the desired libraries. The solution is to use an embedded distribution and ship this with your application. You can find the correct distribution on the official Python download page corresponding to your desired version (here's the link to the lastest 3.9 release which seems to be what you're using: https://www.python.org/downloads/release/python-392/). Look for the Windows Embeddable Package.
You can then simply drop in your .pyd file alongside the standard library files (note that if your third-party library is dependent on any other libraries, you will have to include them, as well). Shipping your application with an embeddable distribution should not only solve your current issue, but will also mean that your application will work regardless of which version of Python a user has installed (or without having Python installed at all).
On windows I have built a very simple "hello world" C extension (the file hello.c from this site https://gist.github.com/physacco/2e1b52415f3a964ad2a542a99bebed8f). Using VS2015 I successfully obtain hello.dll. The problem is that I can't figure out how to import this file/module.
In the python shell (python 3.7) I have made sure that I'm in the same folder as the hello.dll. I have also made sure that sys.path() contains the folder path. But when I write "import hello" I get an error "ModuleNotFoundError: No module named 'hello'"
Does anyone has an idea of what is wrong is this very simple setup?
Update:
When trying to import a module that does not exist the ModuleNotFoundError is reported. After renaming the hello.dll to hello.pyd an ImportError is returned. So it seems like it tries to actually load the module.
Python compiled modules on Windows have the extension .pyd, not .dll. If you'd built it using setup.py the file would be built with the correct name. However, you built it yourself and gave it a name that Python doesn't recognise as a module.
In terms of the build command: you have to link it with libpython. You don't look to be doing this. The error you report is definitely one that you can get if the module is not linked against all its dependencies.
I know you don't want to use setup.py, however I'd use it at least once just to see what it does and if it works. You'll then at least have a command that you can copy with a working set of options.
I have the NAG Fortran compiler installed. I can compile Fortran code by calling nagfor -o helloworld helloworld.f90. If I run f2py with f2py -c -m helloworld helloworld.f90 --fcompiler=nagfor nothing happens. Additionally, if I just run f2py nothing happens. f2py --help-fcompiler gives no output.
I have Windows 7 installed and use the the Anaconda Python distribution. Any idea how I should address this problem?
Following Ian`s comments and this post I managed to run f2py (unfortunately only with the GNU Fortran compiler).
I had to change line 337 in C:\Loopy\Lib\site-packages\numpy\distutils\fcompiler\gnu.py to:
pass #raise NotImplementedError("Only MS compiler supported with gfortran on win64")
Additionally I use C:\Loopy\Scripts\f2py.py.
It's unusual that you aren't seeing any error output at all.
That makes it sound like you're calling something else.
Make sure Anaconda's scripts directory on your path and that you don't have some sort of script in your current directory called f2py.
Depending on how you have your computer is set up to interpret file types, you may need to run something like python f2py.py with the rest of the arguments the same.
If you're using Anaconda, you should already have a copy of gfortran intsalled too.
If you want to use that instead, make sure Anaconda's bin directory is on your path.
Unless you have a very recent (1.10, currently in development) version of numpy, to use gfortran, you'll need to go to Anaconda/Lib/site-packages/numpy/distutils/fcompiler/gnu.py and comment out the lines (somewhere around line 330) that raise an error if you're on 64 bit windows.
Once you've done that, it should work fine.
Edit: judging by the old f2py docs and the current source, the proper fcompiler flag is --fcompiler=nag.
The compiler is specified by vendor, not by executable name.
I just installed ycm, everything looks good, but I found small problem. The problem is as following:
import os # os is built-in library
os. # ycm helps to complete members of the class.
import numpy # numpy is not built-in library, where its location is site-packages.
numpy. # nothing happened. ycm shows 'pattern not found' message.
I think, this would be a simple problem. But I could not find the solution yet. I think, there is some configuration file in which I can define 'search path' for my project.
It would be grateful if I can find a way to solve it.
Best,
Je-Hoon Song
I had the same issue with module 'mpmath' and fixed it in the following manner:
First I retrieved the path where the module was located:
%python3
>>>import mpmath
>>>print(mpmath.__file__)
/usr/lib/python3.4/site-packages/mpmath/__init__.py
Here I found the path of all my "installed" python3 packages to be:
/usr/lib/python3.4/site-packages/
I then simply added to my PYTHONPATH environment variable this path:
%export PYTHONPATH=/usr/lib/python3.4/site-packages/
Then when I used vim sample.py typing import mpmath and following it up with mpmath. YCM showed me all the autocompletions for the mpmath module.
Hope this helps.
I use anaconda python to be my python interpreter in ycm to solve this.
First I modified my vimrc according to full pythong setting in vim.
Then I change g:ycm_python_interpreter_path by
let g:ycm_python_interpreter_path = '/usr/local/anaconda3/bin/python3.8'
In this way I didn't change the system environment variables.
Addtional Info 1:
I think the main problem is that,
my Python interpreter for YCM is my system python (/usr/local/opt/python#3.9/bin/python3.9 ),
which only has limited locally built libraries.
So using the libraries comes with anaconda (/usr/local/anaconda3/bin/python3.8 ) can solve.
Additional Info 2:
By reading :YcmDebugInfo, the main different after edited g:ycm_python_interpreter_path is that:
-- Python completer debug information:
-- Python interpreter: /usr/local/opt/python#3.9/bin/python3.9
-- Python path: ['/usr/local/Cellar/python#3.9/3.9.6/Frameworks/Python.framework/Versions/3.9/lib/python39.zip', '/usr/local/Cellar/python#3.9/3.9.6/Frameworks/Python.framework/Versions/3.9/lib/python3.9', '/usr/local/Cellar/python#3.9/3.9.6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/site-packages']
-- Python version: 3.9.6
change to
-- Python completer debug information:
-- Python interpreter: /usr/local/anaconda3/bin/python3.8
-- Python path: ['/usr/local/anaconda3/lib/python38.zip', '/usr/local/anaconda3/lib/python3.8', '/usr/local/anaconda3/lib/python3.8/lib-dynload', '/usr/local/anaconda3/lib/python3.8/site-packages', '/usr/local/anaconda3/lib/python3.8/site-packages/aeosa', '/usr/local/anaconda3/lib/python3.8/site-packages/locket-0.2.1-py3.8.egg']
-- Python version: 3.8.8
Additional Info 3: about how to read list of locally installed pyton modules
use https://stackoverflow.com/a/740018/11226687
e.g. in my case
$ /usr/local/opt/python#3.9/bin/python3.9
>>> help('modules')
# only return limitted modules
$ /usr/local/anaconda3/bin/python3
>>> help('modules')
# list out all the modules included in Anaconda, including numpy/matplotlib/scipy ect
numpy is kind of a difficult library because it dynamically builds its namespace on import, making it hard for static code analysis tools to know when you're write the code what names should be available. Because the names available in the namespace numpy are only really known at runtime, YCM probably doesn't have any useful suggestions for you.
One simple way to fix is activate your python environment, then open vim. For example
(django_mdn) ➜ locallibrary git:(master) ✗ vim
and in the vim run :echo $PATH.
Then you should be able to see that your venv path is at the first like this:
/Users/gwanghyeongim/.virtualenvs/django_mdn/bin:/usr/local/opt/tcl-tk/bin:...
Then see if your python packages are auto-complete.
It worked.
If you want to set a certain site-packages to be auto complete permanently, you need to make a file called .ycm_ extra_conf.py in your project root directory or global_extra_conf.py and set vim configuration if you want to set it globally.
P.S.
By running export PYTHONPATH=/usr/lib/python3.4/site-packages/ in the shell before opening vim didn't work for me. Besides, unless setting PYTHONPATH permanently, which will cause issue, you will have to set export PYTHONPATH everytime you want dependencies to be auto complete.
I'm trying to install and configure pyIpopt. Ipopt is already installed and the examples run fine.
From the shell, when I do import pyIpopt, I get the error:
ImportError: /***PATH***/libipopt.so.1: undefined symbol: MPI_Init
The FAQ section of the pyIpopt git project has this to offer for these kinds of errors:
Do a Google search to find the library file, and add
-lWhateverLibrary in the makefile of pyipopt.
I've googled and found this: http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Init.html.
I don't know how to get the library or add it to the makefile... Any assistance would be much appreciated!
Just had a similar problem on ubuntu.
Using libmumps-seq worked for me:
installed libmumps-seq-4.9.2 (just with apt-get, along side the ordinary libmumps)
in setup.py changed in the libraries list argument 'coinmumps' to 'dmumps_seq-4.9.2'
rebuilt and installed.
If I understand it correctly, the default mumps is distributed (using MPI lib which can be a world of pain), and all i needed is the sequential one, which mumps-seq provides.