I have a bunch of python code that I would like to "compile" into a shared library with a C interface that can be linked with other C/c++ programs and work without depending on too many other libs (perhaps python and some other dlls but they should all be included into a directory with the final lib).
I don't really want to rewrite the python code into C++ for this. I can of course, but it would be best to have a standalone lib that can be used like a dll/so lib.
I have tried cython and wanted to compile python to C and then just compile C code into a dll but that doesn't seem to work quite yet (I haven't been able to make it work flawlessly yet). And then I also tried bbfreeze - but does bbfreeze support creating an .so file? Wasn't able to find out how to do it. Does anyone know?
Do you know of any other options that are more straightforward? the python code only needs to be compiled once. And best of all would be if it creates a single .so file no matter how big it is that just works without too many dependencies.
You can use Python as a library from inside your C++ application: it's called the Python/C API.
The idea is that you initialize your own interpreter, then you load a script in it. You can expose your C++ objects through global variables or modules inside the Python interpreter for your code to interact with, your you can just run Python functions directly from your C++ code.
Now, I understand that you might want to have your Python scripts embedded inside the shared library: this is not necessarily an easy task, with the traditional GNU toolchain. There are multiple techniques to achieve this, but none is official, and all seem way too complicated as opposed to just having the script in an external file.
If your goal is to hide the scripts from the end-user, you could sign them or encrypt them with a private key and embed the public key inside your library, but keep in mind that the key can easily be retrieved by anyone with enough motivation.
Related
I have a strange use case. I have a C++ program that compiles a library object and dynamically loads it at runtime. The library it compiles depends on a third party dependency, which so far I have been solving by manually hard coding the path and changing it when I switch computers.
Is there a way to call pkg-config from C++ to ask it if a library is installed and where? I know I could call it from a bash session and parse the output, but this is not what I want, I would like to call it directly instead of invoking a shell if that is possible.
Is there a C/C++ APIfor pkg-config?
Yes, there is a C api. https://github.com/pkgconf/pkgconf/blob/master/libpkgconf/libpkgconf.h , which should get installed with libpkgconf.so shared library.
I am working on a program which from a c++ code generates a .so and bindings for multiple languages (C, C++, Haskell, Java, Php, Python...) and I'm trying to add support for golang.
I think the best way to get that result is to either use the C++ or the C version and create go bindings, but this has to be done automatically. I've tried using Swig but I didn't manage to get it working (likely because we're including a .so and not a .cc) and I've only found old documentation (this uses go tool 6g).
I've also tried creating bindings with cgo which doesn't work with C++, and I couldn't get it working with the C bindings (again, most likely because of the .so step).
At the end, I must generate another .so with a few exported functions, and which must be standalone which makes compiling the C++ version and talking with it through a pipe (almost?) impossible.
The functions to export are often things like:
void init_game(void);
void play_turn(void);
void end_game(void);
You can find a c++ header here and the auto-generated interfaces to C: interface.hh and interface.cc and prologin.h.
An example source code of lib.so can be found here.
I have a C++ project that was used to create a DLL. Is it possible to take that C++ code and create a DYLIB file? I have only done a tiny bit of work with C++, so I am not sure if this can easily be done. Basically, I have an app that I rewrote in Python so I could run it on Windows or macOS. The Windows version of the app is able to use the DLL without a problem. Now, I would like to use the library with the macOS version of the app.
In general, of course, it is possible. However, whether it will be an easy job or not depends on whether how the library was written.
In the best case: you only need to recompile the library in macOS following its build instructions (e.g. typically explained in the documentation or in a README-style file in the root of the project).
In the worst case: the library is not portable at all (e.g. depends on the Windows API) and you won't be able to use it without rewriting it.
A side question is whether you really need the library: it is possible that you can find a Python library to fulfill the same job.
How can I use a library such as the GMP library in C++ in such a manner that the file can be compiled normally without having the person compiling to install the GMP themselves. This is for personal use(so no license issues etc.). I just want my client to be able to compile my C++ code which needs the GMP library. I tried using g++ -E option, and it kinda works, but the problem is that on top of it are included many files which are themselves part of the library(and not available without the lbrary). Also the linker needs the availability of the library even if I do do that successfully.
How do I copy the entire library per se, maintaining a single file of code, such that it compiles and doesn't cause problems. I'm quite sure it is doable, because copying some functions works like a charm, but I can't copy paste the 3000 line code manually, so how to do it?
If I understand you correctly, I guess what you want is to have your source and the entire GMP library in one file? And you want to do that automated?
I think there is no standard way to do this. You could write a script in you favorite language (bash, python, etc) which traverses the GMP code tree, appending the files (first the header files, then the cpp files) to your file while ignoring all local #include-lines. And hope that there are not too many macros etc which rely on the folder structure to be intact.
However, you could (and probably should) just supply the library and a adequate Makefile with your source code. Then the client wouldn't need to install the GMP lib, but could unpack the archive and run make. If the constraint is to do this in one file, maybe it is wiser to change that constraint...
I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.