Calling a shared library from c++ - c++

i have a shared library with some functions stored inside it. i want to Access those functions by calling that library from another program. I have done this earlier in C.
Now i want to do the same using C++. I am pretty new to C++ and any suggestions are very much required. BTW, the shared library is written in C. Is it still possible for me to call this in a C++ program and use all the functions of it.
Please help me. An example program would be very very helpful.
i am using ubuntu 14.04 and the compiler is the native g++ that comes along with it.

Load shared libarary using dlopen, and load given symbol using dlsym. Link with -ldl.
So given a shared library hello.cpp, compile g++ -shared -fPIC -o libhello.so hello.cpp
#include <cstdio>
extern "C" void hello( const char* text ) {
printf("Hello, %s\n", text);
}
(shared libraries should be named lib*.so[.*])
Now calling in main.cpp, compile: g++ -o main main.cpp -ldl
#include <dlfcn.h>
extern "C" typedef void (*hello_t)( const char* text );
int main() {
void* lib = dlopen("./libhello.so", RTLD_LAZY);
hello_t hello = (hello_t)dlsym( lib, "hello" );
hello("World!");
dlclose(lib);
}
See C++ dlopen mini HOWTO.

You said you already did so in C. Actually C++ is based on C, so you still can do it in the same way you did before.
Usually the following steps are required:
Use some method provided by the library in your c++ code
Figure out which header provides that method, and include it in your .cpp file
Compile your C++ code against the headers of the library (compiler flags in the Makefile)
Link against the library ( Linker Flags in the Makefile )

Related

JNI and shared library

Trying to create dll.
So first I created a .java file as follows:
class Main
{
static
{
System.loadLibrary("sample_dll");
}
static native void sritest();
public static void main(String [] a)
{
sritest();
}
}
Then I compile it with no error to .class.
Then using javah I created Main.h.
Then I write following code in c++.
#include <jni.h>
#include <Main.h>
JNIEXPORT void JNICALL Java_Main_sritest(JNIEnv *env,jobject obj)
{
printf("hi");
}
Then I compiled this using MinGw by the following code
g++ -c sample_dll.cpp
g++ -shared -o sample_dll.dll sample_dll.o
Then I place this in java library path.
Then I run Main.java but the following exception occurs
Unstatisfied link error; sritest ()V
I find an answer . It is i do three mistakes. When compiling with c++ we must declare my jni function in extern "C"{} block. Second when compiling in minGW compiler we should use following code and implement include folder of jdk . The code now worked and my program runs smoothly without problem in jni.
The command line code for compiling .o to .dll code is after creating sample_dll.o we must do
g++ -Wall -D_JNI_IMPLEMENTATION -Wl,--kill-at -Ic:/path_of_include_folder_in_jdk_without_drive_letter -Ic:/path_of_win32_folder_in_include_folder_in_jdk_without_drive_letter -shared -o sample_dll.dll sample_dll.o
The last mistake is i want to include Main.h compiled by javah utlity that created from my java code.
This is done by
Javac Main.java
Javah Main
Then take the header file Main.h created and place it in the c++ compiler's include folder. That in my computer c:\minGW\include .
In c++ code add additional preprocessor
#include<Main.h>
All done create dll and place it in one of default java library path . The paths can be getted by using the following function in java
System.out.println (System.getProperty ("java.library.path"));

Compiling and Linking Leda 6.3

I am new to LEDA and I am working on LEDA6.3 Free Edition on OpenSuse 12.1.
As a start I tried to write a simple code "Hello LEDA world" as in the manual http://www.leda-tutorial.org/en/official/ch01s02.html.
#include <LEDA/string.h>
#include <iostream>
using leda::string;
using std::cout;
int main()
{
string msg = "Hello LEDA world!";
cout << msg << "\n";
}
The compilation phase works fine and I generated the .o file.
But they mentioned that this file needs to be linked to the LEDA library and the only library available in the Free edition is the libleda.a and libleda.so
I am trying to link using the following command:
g++ -o welcome welcome.o -L$LEDAROOT -llibleda
What I get is:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: cannot find -llibleda
I was wondering if someone could help me with how to link my file with the leda library ? so I can get it to run.
Thanks all.
It is unlikely that the library file is called liblibleda.a or liblibleda.so: when the linker sees a an option of the form -l<name> it will search for a library file named lib<name>.so (for shared libraries) or lib<name>.a (for static libraries). You probably just want to use the option -lleda (unless the LEDA developers did something clever and called the library something like libeda.a so you'd use -leda).
Whether this works will also depend on the compiler options being consistent between the installation and your build.

typeid of enum changing when dynamically linked in matlab mex file

I have a C++ library with a particular function that returns a boost::any, whose value type is a particular enum defined in a different included library. This normally works fine.
But when I link to my library dynamically from a Matlab mex file, typeid(the_enum_t) seems to be different for the things made in my library and those made in the caller, in that it doesn't compare ==. Since I'm actually using flann, whose version of boost::any performs a check based on type_info::==, this makes everything break. Static linking works fine, but that's kind of a pain here, and I'd really rather have it work either way.
I thought type_info::== was supposed to work consistently across library boundaries. Does this have to do with how Matlab dynamically loads libraries from mex?
Here's some code to reproduce this (also available in easy-to-download form, with a makefile, in this gist).
First, a stand-in for the library that defines the enum (flann):
namespace library {
enum the_enum_t { el_one, el_two, el_three };
}
Now a proxy for my library, stubby.hpp:
#include <boost/any.hpp>
#include "the_enum.hpp"
boost::any the_function();
And its implementation stubby.cpp:
#include "stubby.hpp"
boost::any the_function() {
return boost::any(library::el_two);
}
Finally, test code test.cpp, which is compiled with -DNO_MEX for a standalone and not for a mex file:
#include "stubby.hpp"
#include <boost/any.hpp>
#ifdef NO_MEX
#include <cstdio>
using std::printf;
int main() {
#else
#include "mex.h"
void mexFunction(int nlhs, mxArray **plhs, int nrhs, const mxArray **prsh) {
#endif
boost::any val_any = the_function();
printf("%s (equal: %d)\n",
val_any.type().name(),
val_any.type() == typeid(library::the_enum_t));
}
I get the expected output
N5flann17flann_algorithm_tE (equal: 1)
from each of
$ g++ -o test{,.cpp} -DNO_MEX libstubby.a && ./test
$ g++ -o test{_s,.cpp} -DNO_MEX libstubby.so && ./test_s
$ ln -sf test{,_s}.cpp && mex test_s.cpp libstubby.a && matlab -r test
But dynamically linking a mex file doesn't work:
$ mex test.cpp libstubby.so && matlab -r test
N5flann17flann_algorithm_tE (equal: 0)
I see this same behavior on
Matlab R2011b and R2011a, OSX 10.7, Apple gcc 4.2.1
Matlab R2011b, CentOS 5.7, gcc 4.1.2
Matlab R2010a, Ubuntu 11.04, gcc 4.4.5
The weird thing is that I could've sworn it worked a few months ago, but maybe I just did a bad job of testing.
Obviously I can get around this by static linking. But why is this happening? Does it have something to do with the way Matlab loads mex files and their libraries?
Boost has a workaround for this issue; see https://svn.boost.org/trac/boost/ticket/754
It's possible that boost is failing to enable the workaround. Try passing compiler flag -DBOOST_AUX_ANY_TYPE_ID_NAME per the patch on that ticket.

Exporting constants from a DLL

I'm working with VC9 on Windows.
I have a library (lets call it libfoo) which is made of the following files ("include guards" and "#include" directives omited for clarity's sake):
// foo.hpp
class Foo
{
public:
static const std::string SOME_CONST;
};
And:
// foo.cpp
#include "foo.hpp"
const std::string Foo::SOME_CONST = "hello";
Foo::SOME_CONST is exported using a .def file.
The library compiles fine: a libfoo.lib file and a libfoo.dll file are generated.
I used this library in a sample program, like:
// main.cpp
#include <foo.hpp>
int main()
{
std::cout << Foo::SOME_CONST << std::endl; // std::bad_alloc here
return EXIT_SUCCESS;
}
A std::bad_alloc is thrown whenever I attempt to use Foo::SOME_CONST.
This only happens if I link dynamically to libfoo. Linking statically results in a perfectly working program.
What could possibly be going on here ? Is it legal to export a std::string constant that way ?
Check if dll actually does dynamic initialization, because it might not, standard has no requirements for dynamic libraries. Wrapping globals in static functions can be the solution.
Use __declspec(dllexport) and __declspec(dllimport). Stop worrying about .def files and all of that rubbish- let the compiler do the work.
Are the library and the main application linking to the same version of the standard library and/or CRT and/or MFC, with exactly the same settings? I've seen allocation issues when using different versions of the CRT, and also fought bugs caused by different iterator debugging settings between a library and its including application.

Python importing & using cdll (with a linux .so file)

After one of my last questions about python&c++ integration i was told to use dlls at windows.
(Previous question)
That worked ok doing:
cl /LD A.cpp B.cpp C.pp
in windows enviroment, after setting the include path for boost, cryptopp sources and cryptopp libraries.
Now i'm tryting to do the same in linux, creating a .so file to import through ctypes on python2.5.
I did:
gcc -Wall -Wextra -pedantic A.cpp B.cpp C.cpp /usr/lib/libcryptopp.so -shared -o /test/decoding.so
and the so object is created ok. If removed "-shared" compilation is OK but stops as no main in there (obviously ;) ). Of course libcryptopp.so exists too.
But when i go to python and import the "so" file, it said that the attribute has no object "decrypt", "encrypt" or whatever i put there. using "dir" over the dll objects confirms that they are not there.
external functions are defined in A.cpp as:
int encrypt (params...)
//..
return num;
int decrypt (params...)
//..
return num;
also tried using:
extern "C" encrypt (params...)
.....
Could anyone tell me what i'm doing wrong?
Thanks in advance!
Rag
C++ compiler mangles names of functions. To do what you are trying to do you must have the declaration prototype inside
extern "C" {...}
it's hard to tell from your samples what exactly you have in a source file.
As someone already mentioned, use nm utility to see what objects that are in your shared object.
Do not compile your object without -shared. Python load library does not support statically linked objects as far as am aware.
compile your object with g++ compiler instead, it will link to standard C++ Library, gcc does not.
just to doublecheck something since you using boost.
#include <string>
#include <boost/python.hpp>
using namespace std;
string hello(string s){
return "Hello World!";
}
BOOST_PYTHON_MODULE(pyhello){
using namespace boost::python;
def("hello", hello);
}
in python
>>> import pyhello
>>> print pyhello.hello()
Hello World!
just my 2 cents, sorry if this couldn't help you.