CODEWITHSUNDEEP
c++shared-librariesdlopendlsym
moo
moo

Reputation: 526

C - Shared Library - dlopen, dlsym

for a research topic, I am using a C++ program to translate a SQL query into a C++ program. After translation, the c++ query source-code is compiled into a shared library:

g++ -O0 -g3 -fPIC -std=c++0x GeneratedQuery.cpp ../type/Types.cpp -shared -o lib.so

Everything works fine and the library is compiled correctly. In a second program, I try to implement a read-eval-print-loop which takes a query from the user, translates and compiles it, loads the shared library with dlopen and dlsym, and finally executes it. Before I used Intel TBB in the query-code everything worked fine, but now I get a segmentation fault for the second query I enter (fist query works perfectly, but second query that is loaded in the loop fails).

Source (read-eval-print-loop): http://pastebin.com/pWkRN7Dx

Sample Query-Code: http://pastebin.com/A1pBZC3d

If I do not have a join in my query and thus a single parallel_for occurs in the query source-code, there is no problem. But if there are multiple parallel_fors, I get a segmentation fault for the second query I enter (compilation is successful and dlopen works, but dlsym fails).

Here is the gdb output

0x00007ffff7de394b in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7de429e in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7de4523 in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff6cc612a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff7bd7044 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff7de9176 in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7bd752f in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff7bd709a in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
0x000000000041fd58 in main (argc=1, argv=0x7fffffffe1d8) at ../src/tpcc.cpp:141

I really don't understand what fails for the second query. I tried different flags for dlopen, but it didn't work for any combination.

Hope someone can help me, as I am very unexperienced in shared libraries.

Regards

Upvotes: 0

Views: 2044

Answers (3)

moo
moo

Reputation: 526

Got it running, but I am still confused:

If I give each library file an other name, like lib..so and load it, everything works fine. Is there something like a cache which could lead to the described behaviour above?

Upvotes: 0

Jose Palma
Jose Palma

Reputation: 756

I am not really sure if what I am saying it is correct or not, but I remember had a simillar problem last year and I solved it generating the .so with the libraries included. Something like this:

g++ -O0 -g3 -fPIC -std=c++0x GeneratedQuery.cpp ../type/Types.cpp {add intel stuff here .a etc} -shared -o lib.so

I used CMAKE and I had to add to add_library stuff.

I hope this helps, if not apologies!.

Upvotes: 1

user2743554
user2743554

Reputation: 543

Try to replace

extern "C" { void run { ... } }

to

extern "C" void run { ... }

See explanation in the great http://www.isotton.com/devel/docs/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html paper.

Upvotes: 3

Related Questions