Hi
I want to use dlopen to load a dll in my application, The dll uses
several symbols avail in the executable.
I’m having much trouble getting this to work, always getting segfault in
the dlopen routine. I have compiled the .so with -fPIC and -shared.
Is there some do/Don’t list of what todo with dll’s?
How do i check what is wrong?
I tried DL_DEBUG=1 ,it didn’t give me any info on why I get a segfault
though.
/Johan Björk
phearbear wrote:
Hi
I want to use dlopen to load a dll in my application, The dll uses
several symbols avail in the executable.
I’m having much trouble getting this to work, always getting segfault in
the dlopen routine. I have compiled the .so with -fPIC and -shared.
Is there some do/Don’t list of what todo with dll’s?
How do i check what is wrong?
I tried DL_DEBUG=1 ,it didn’t give me any info on why I get a segfault
though.
You need to link your executable with:
-Wl,-E
in order to tell the linker that the symbols in the executable
might be used by shared libs opened after startup.
Cheers,
Andrew
Andrew Thomas wrote:
phearbear wrote:
Hi
I want to use dlopen to load a dll in my application, The dll uses
several symbols avail in the executable.
I’m having much trouble getting this to work, always getting segfault
in the dlopen routine. I have compiled the .so with -fPIC and -shared.
Is there some do/Don’t list of what todo with dll’s?
How do i check what is wrong?
I tried DL_DEBUG=1 ,it didn’t give me any info on why I get a segfault
though.
You need to link your executable with:
-Wl,-E
in order to tell the linker that the symbols in the executable
might be used by shared libs opened after startup.Cheers,
AndrewJust tried doing this, didn’t help and I am getting segf at the same
time as before.
Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
/Johan
“phearbear” <phearbear@home.se> wrote in message
news:3D086378.5040201@home.se…
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble. If
you can post
something that I can build and execute, I’ll compare it to our own build
process to
try to find the difference.
Cheers,
Andrew
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble. If
you can post
something that I can build and execute, I’ll compare it to our own build
process to
try to find the difference.Cheers,
Andrew
\
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?
/Johan
I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work just fine
Sreekanth
“phearbear” <phearbear@home.se> wrote in message
news:3D09B53F.9050402@home.se…
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble.
If
you can post
something that I can build and execute, I’ll compare it to our own build
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
Sreekanth wrote:
I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work just fineSreekanth
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D09B53F.9050402@home.se> …Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble.If
you can post
something that I can build and execute, I’ll compare it to our own build
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
\
I am pretty sure my problem must lay in the .so, probably it isn’t fully
compiled with -shared or something. Is there some way to check what part
of a library that might not be compiled correctly?
I tried with a ‘dummy’ .so. It loaded okay, but when calling dlclose it
crashed.
Is this the bug you where talking about?
I just did some more testing, if I removed the dlsym call (which
obviously fails on my dummy dll) the dlclose worked perfectly.
/Johan
This is a known issue when using the Dinkum Full C++ library.
A problem report exists in our database for this issue.
Sreekanth wrote:
I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work just
fineSreekanth
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D09B53F.9050402@home.se> …Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble.If
you can post
something that I can build and execute, I’ll compare it to our own
build
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
I am pretty sure my problem must lay in the .so, probably it isn’t fully
compiled with -shared or something. Is there some way to check what part
of a library that might not be compiled correctly?
I tried with a ‘dummy’ .so. It loaded okay, but when calling dlclose it
crashed.
Is this the bug you where talking about?
I just did some more testing, if I removed the dlsym call (which
obviously fails on my dummy dll) the dlclose worked perfectly./Johan
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
Be careful about using instantiate an object with virtual function
in share memory. It will guarantee crash as I found out after
debugging c++ + .so problems for 3 days. The virtual function
table can not be located in share memory since the vtable is pointer to
code in share library which usually loaded in different
process virtual address.
Single step your .so code with gdb helps debugging.
Objects/classes without virtual functions work fine.
–
-Tony Lee
Jeff Baker wrote:
This is a known issue when using the Dinkum Full C++ library.
A problem report exists in our database for this issue.Odd, I am using the GNU C++ library.
Sreekanth wrote:I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work justfine
Sreekanth
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D09B53F.9050402@home.se> …
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no trouble.If
you can post
something that I can build and execute, I’ll compare it to our ownbuild
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
I am pretty sure my problem must lay in the .so, probably it isn’t fully
compiled with -shared or something. Is there some way to check what part
of a library that might not be compiled correctly?
I tried with a ‘dummy’ .so. It loaded okay, but when calling dlclose it
crashed.
Is this the bug you where talking about?
I just did some more testing, if I removed the dlsym call (which
obviously fails on my dummy dll) the dlclose worked perfectly./Johan
\
“phearbear” <phearbear@home.se> wrote in message
news:3D0AFB66.6010708@home.se…
Jeff Baker wrote:
This is a known issue when using the Dinkum Full C++ library.
A problem report exists in our database for this issue.Odd, I am using the GNU C++ library.
Sorry, my mistake. When you’re debugging, do a ‘shared’ after the .so is
dlopened. Step to the end of the main function and then ‘si’ into the
cleanup code until it crashes. This will give you a better idea of where
the crash is coming from… if you haven’t done this already, that is.
Sreekanth wrote:
I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work justfine
Sreekanth
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D09B53F.9050402@home.se> …
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have no
trouble.If
you can post
something that I can build and execute, I’ll compare it to our ownbuild
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give
some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
I am pretty sure my problem must lay in the .so, probably it isn’t fully
compiled with -shared or something. Is there some way to check what part
of a library that might not be compiled correctly?
I tried with a ‘dummy’ .so. It loaded okay, but when calling dlclose it
crashed.
Is this the bug you where talking about?
I just did some more testing, if I removed the dlsym call (which
obviously fails on my dummy dll) the dlclose worked perfectly./Johan
\
Jeff Baker wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D0AFB66.6010708@home.se> …Jeff Baker wrote:
This is a known issue when using the Dinkum Full C++ library.
A problem report exists in our database for this issue.
Odd, I am using the GNU C++ library.
Sorry, my mistake. When you’re debugging, do a ‘shared’ after the .so is
dlopened. Step to the end of the main function and then ‘si’ into the
cleanup code until it crashes. This will give you a better idea of where
the crash is coming from… if you haven’t done this already, that is.
Sreekanth wrote:
I understand there is some issue in calling dlclose on a C++ dynamic
library.But i too use c++ .so files in my project and they work justfine
Sreekanth“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D09B53F.9050402@home.se> …
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D086378.5040201@home.se> …
Just tried doing this, didn’t help and I am getting segf at the same
time as before.Program received signal SIGSEGV, Segmentation fault.
0x082ced9f in resolve_rels ()
Any other ideas?
Can you post a complete example (with makefile) that exhibits this
behaviour? We
are loading .so files using dlopen() all the time, and have notrouble.
If
you can post
something that I can build and execute, I’ll compare it to our ownbuild
process to
try to find the difference.Cheers,
Andrew
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could givesome
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
I am pretty sure my problem must lay in the .so, probably it isn’t fully
compiled with -shared or something. Is there some way to check what part
of a library that might not be compiled correctly?
I tried with a ‘dummy’ .so. It loaded okay, but when calling dlclose it
crashed.
Is this the bug you where talking about?
I just did some more testing, if I removed the dlsym call (which
obviously fails on my dummy dll) the dlclose worked perfectly./Johan
\
Hi again
Gave up on the problem for a while but i’m back trying to stab on it a
bit now.
Just tried the ‘si’ trick and the results is very much confusing me.
If I ‘si’ through the whole dlopen() call, I get no segfault!
simply ‘s’ pass the dlopen give me a segfault though 
Ideas?
Found one issue with my application though. I was linking too both the
static and the shared libph as I am using the PtNumericFloat widget.
Realized i must use the libphS for it to work (…i think?)
/Johan
“phearbear” <phearbear@home.se> wrote in message
news:3D20AD91.6020504@home.se…
Hi again
Gave up on the problem for a while but i’m back trying to stab on it a
bit now.
Just tried the ‘si’ trick and the results is very much confusing me.
If I ‘si’ through the whole dlopen() call, I get no segfault!
simply ‘s’ pass the dlopen give me a segfault though >Ideas?
Found one issue with my application though. I was linking too both the
static and the shared libph as I am using the PtNumericFloat widget.
Realized i must use the libphS for it to work (…i think?)
That might be your issue. If your shared library is linked against a
static library, then the objects in the static library must be built with
the -fPIC flag. QSSL does not use -fPIC when building static
libraries, so you cannot solve this problem. The only work-around
is to link your main executable against libphS, and then make sure
that your shared library does not link against libphS. Now you
need to use -shared during the link step for your main executable
so that your shared library can resolve symbols from the
executable when it loads.
This would all go away if
a) the dynamic Photon libs had the same functions as the static
Photon libs, or
b) QSSL compiled their static libs with -fPIC.
Both of these have been requested numerous times over the last
few years. I haven’t investigated the current status of things
recently to see what steps have been taken to address this issue.
Cheers,
Andrew
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D20AD91.6020504@home.se> …Hi again
Gave up on the problem for a while but i’m back trying to stab on it a
bit now.
Just tried the ‘si’ trick and the results is very much confusing me.
If I ‘si’ through the whole dlopen() call, I get no segfault!
simply ‘s’ pass the dlopen give me a segfault though >Ideas?
Found one issue with my application though. I was linking too both the
static and the shared libph as I am using the PtNumericFloat widget.
Realized i must use the libphS for it to work (…i think?)
That might be your issue. If your shared library is linked against a
static library, then the objects in the static library must be built with
the -fPIC flag. QSSL does not use -fPIC when building static
libraries, so you cannot solve this problem. The only work-around
is to link your main executable against libphS, and then make sure
that your shared library does not link against libphS. Now you
need to use -shared during the link step for your main executable
so that your shared library can resolve symbols from the
executable when it loads.This would all go away if
a) the dynamic Photon libs had the same functions as the static
Photon libs, or
b) QSSL compiled their static libs with -fPIC.Both of these have been requested numerous times over the last
few years. I haven’t investigated the current status of things
recently to see what steps have been taken to address this issue.Cheers,
Andrew
I don’t use photon at all from my plugin.
I can’t link with -shared for my main executable, QCC will then link it
as a library and it won’t be a executable no more.
b) is solved, as the *S.a libraries are compiled with -fPIC, that’s the
whole point 
/Johan
“phearbear” <phearbear@home.se> wrote in message
news:3D24C5F0.2060408@home.se…
Andrew Thomas wrote:
“phearbear” <> phearbear@home.se> > wrote in message
news:> 3D20AD91.6020504@home.se> …Hi again
Gave up on the problem for a while but i’m back trying to stab on it a
bit now.
Just tried the ‘si’ trick and the results is very much confusing me.
If I ‘si’ through the whole dlopen() call, I get no segfault!
simply ‘s’ pass the dlopen give me a segfault though >Ideas?
Found one issue with my application though. I was linking too both the
static and the shared libph as I am using the PtNumericFloat widget.
Realized i must use the libphS for it to work (…i think?)
That might be your issue. If your shared library is linked against a
static library, then the objects in the static library must be built
with
the -fPIC flag. QSSL does not use -fPIC when building static
libraries, so you cannot solve this problem. The only work-around
is to link your main executable against libphS, and then make sure
that your shared library does not link against libphS. Now you
need to use -shared during the link step for your main executable
so that your shared library can resolve symbols from the
executable when it loads.This would all go away if
a) the dynamic Photon libs had the same functions as the static
Photon libs, or
b) QSSL compiled their static libs with -fPIC.Both of these have been requested numerous times over the last
few years. I haven’t investigated the current status of things
recently to see what steps have been taken to address this issue.Cheers,
Andrew
I don’t use photon at all from my plugin.
In that case, linking your executable with libphS should not make any
difference at all. You only need -fPIC for code that is contained in,
or linked to, a shared object.
I can’t link with -shared for my main executable, QCC will then link it
as a library and it won’t be a executable no more.
Sorry, I was thinking -rdynamic (-Wl,-E) but said -shared. -rdynamic
doesn’t (didn’t used to) work in QNX6, but -Wl,-E does the same
thing.
b) is solved, as the *S.a libraries are compiled with -fPIC, that’s the
whole point >
That’s good to know.
Does your dynamic library have a constructor? Is it possible that
your crash is occuring at that point?
Have you had any luck generating a simplified example that you
can post?
Cheers,
Andrew
Tony Lee wrote:
I’ve tried doing a simple example, but ofcaurse that works ;/
My code is C++ if that can have anything todo with it.
will have to look at it even more, i was hoping someone could give some
list about all stuff you need to think about when doing dll’s.
What params are you to use as a second param to dlopen?/Johan
Be careful about using instantiate an object with virtual function
in share memory. It will guarantee crash as I found out after
debugging c++ + .so problems for 3 days. The virtual function
table can not be located in share memory since the vtable is pointer to
code in share library which usually loaded in different
process virtual address.Single step your .so code with gdb helps debugging.
Objects/classes without virtual functions work fine.
–
-Tony Lee
\
Hi again
Sorry for the delay, I was once again looking into the problem, and this
is most certainly the problem.
Is there any workarounds/anything, except redoing the app/plugin system
,to something without virtuals ?
/Johan