I am new to Cython and I wanted to wrap a simple c-function to python. In the C-File i use: #include<complex.h>
When i try to build the wrapper i get following error:
lib/mandelbrot_c.c(10): error C2146: Syntaxfehler: missing";" before "c"
lib/mandelbrot_c.c(10): error C2065: "c": not declared
lib/mandelbrot_c.c(10): error C2065: "z": not declared
...
The problem is that the macro does not work i guess.
The code used in the c-file is: double complex c, z;
The files can be found here:
https://github.com/HaidStefan/python_wrap_c_libraries/tree/dev/cython
Does anyone know a solution for this? Sorry if this question is dumb but i am new to cython and I'm trying to make a benchmark between different wrappers.
Thanks a lot in advance
Stefan
The complex library from the C99 standard library is not supported fom the MSVC compiler, which is used to build cython.
See: Compiling C code in Visual Studio 2013 with complex.h library
Related
I'm building a package tested for CUDA 9,10 from source, trying to compile it for CUDA11.
I've already changed gencode=arch=compute_70 (was set on 30), and added
target_link_libraries(tsnecuda ${CUDA_cusparse_LIBRARY})
Unfortunately, I still get
tsne-cuda/src/util/math_utils.cu(153): error: identifier "cusparseScsr2csc" is undefined
tsne-cuda/src/util/math_utils.cu(165): error: identifier "cusparseXcsrgeamNnz" is undefined
tsne-cuda/src/util/math_utils.cu(195): error: identifier "cusparseScsrgeam" is undefined
3 errors detected in the compilation of "tsne-cuda/src/util/math_utils.cu".
CMake Error at tsnecuda_generated_math_utils.cu.o.cmake:276 (message):
Error generating file
tsne-cuda/build/CMakeFiles/tsnecuda.dir/src/util/./tsnecuda_generated_math_utils.cu.o
Is there a chance the build process somehow ignores my target_link_libraries? Should I add something else?
Undefined identifier is a compilation issue, not a linking issue.
At least part of the problem here is that CUDA deprecated and removed some functionality from cusparse, including cusparse<t>csr2csc(). The code would need to be rewritten to compile correctly under the latest versions of CUDA 11.x.
For example, for csr2csc, the call to cusparseScsr2csc might be refactored to use this function instead.
One example of deprecation/removal notice for cusparse<t>csr2csc is given here.
I am attempting to use the LMDB C API with Cython.
I want to import the following definitions from the header file:
typedef struct MDB_env MDB_env;
int mdb_env_create(MDB_env **env);
So I created a .pxd file:
cdef extern from 'lmdb.h':
struct MDB_env:
pass
int mdb_env_create(MDB_env **env)
And I am using it in a Cython script:
cdef MDB_env *e
x = mdb_env_create(&e)
This code compiles fine, but If I run it, I get:
ImportError: /home/me/.cache/ipython/cython/_cython_magic_15705c11c6f56670efe6282cbabe4abc.cpython-36m-x86_64-linux-gnu.so: undefined symbol: mdb_env_create
This happens both in a Cython .pyx + .pxd setup and in a prototype typed in IPython.
If I import another symbol, say a constant, I can access it. So I seem to be looking at the right header file.
I don't see any discrepancy between my syntax and the documentation, but I am clearly doing something wrong. Can somebody give me a hint?
Thanks.
To compile it with IPythons-magic (would be nice if you would mention this explicitly in your question) you have to provide library-path (via -L-option) and library name (via -l-option) of the built c-library you want to wrap, see also the documentation:
%%cython -L=<path to your library> -l=<your_library>
The library you are trying to wrap is not a header-only library. That means that some symbols (e.g. mdb_env_create) are only declared but not defined in the header. When you build the library, the definitions of those symbols can be found in the resulting artifact, which should be provided to the linker when your extension is built. These definitions is what is needed when the program runs.
If you don't do it, the following happens on Linux: When the extension (the *.so-file) is built,the linker allows undefined symbols per default - so this step is "successful" - but the failure is only postponed. When the extension is loaded via import, Python loads the corresponding *.so with help of ldopen and in this step loader checks that the definitions of all symbols are known. But we didn't provide a definition of mdb_env_create so, the loader fails with
undefined symbol: mdb_env_create
It is differently for symbols which are defined in the header-file, for example enums MDB_FIRST&Co - the compiled library isn't necessary and thus the extension can be loaded, as there are no undefined symbols.
I am trying to use the GSL library in a Cython program but don't seem to have the paths correctly specified; I encounter the following error when I try writing a simple example:
%load_ext cythonmagic
%%cython -lgsl -lgslcblas
cdef extern from "gsl/gsl_ran_poisson_pdf.h":
double gsl_ran_poisson_pdf(int x, double mu)
def poison(int x, double mu):
return gsl_ran_poisson_pdf(x,mu)
/Users/name/.ipython/cython/_cython_magic_189673701925d12059c18b75663da8bd.c:317:10: fatal error:
'gsl/gsl_mode.h' file not found
#include "gsl/gsl_mode.h"
I get the same error using CythonGSL and the demo program here: http://nbviewer.ipython.org/github/twiecki/CythonGSL/blob/master/examples/cython_gsl_ipythonnb.ipynb
The GSL libraries are located in the following directories:
-I/usr/local/include
-L/usr/local/lib -lgsl
I know that similar questions have been asked on SO before, but I couldn't find one relevant to my situation and system (I'm using OS-X). Any help would be appreciated.
Thanks!
I wanted to launch the process from firebreath,so I included "boost/process.hpp". Just including this header alone throws compile error.
could some one help?
FireBreath 1.6.1, FireBreath 1.7.0,windows 8
Error:
2>C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/process/detail/pipe.hpp(129): error C2665: 'boost::system::system_error::system_error' : none of the 7 overloads could convert all the argument types
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(39): could be 'boost::system::system_error::system_error(int,const boost::system::error_category &,const std::string &)'
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(43): or 'boost::system::system_error::system_error(int,const boost::system::error_category &,const char *)'
2> while trying to match the argument list '(DWORD, overloaded-function, const char [54])'
I faced same problem
boost: 1.47
OS: Windows XP (32 bit VM)
But not with FireBreath
I changed boost::system::system_category to boost::system::system_category() in pipe.hpp line 129
the boost::process library that was in FireBreath has compilation errors in them. I have fixed those errors and it now compiles for me, at least when including . I haven't actually tried to use it on windows yet, nor I suspect has anyone else.
Good luck, hope that helps.
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.