Hi everyone
When opening a .so (C++) with dlopen using the parameters
int main() {
a = dlopen(bleh.so,RTLD_NOW|RTLD_GLOBAL);
dlclose(a);
printf(“We are lucky\n”);
}
it opens and closes fine.
However, if I specify
RTLD_NOW|RTLD_LOCAL
It crashes in dlclose!!
The backtrace is a bit different depending if I use dinkum or gnustdc++.
using dinkum the backtrace is something like this (Sorry, doing this at
another computer)
_dlclose,_fini,_btext,“global destructors keyed to
std::ios_base::Init::_Init_cnt”, 0xXXXX
Anyone know what might be causing this?
The dll is a plugin for the MMedia Framework so changing the dlopen is not
possible…
Any ideas is appriciated!
/Johan Björk
The backtrace is a bit different depending if I use dinkum or gnustdc++.
using dinkum the backtrace is something like this (Sorry, doing this at
another computer)
_dlclose,_fini,_btext,“global destructors keyed to
std::ios_base::Init::_Init_cnt”, 0xXXXX
Anyone know what might be causing this?
The dll is a plugin for the MMedia Framework so changing the dlopen is not
possible…
Yeah, it has to do with when the shlib’s get unopened. Basically you cannot
dlopen() a shlib that needs C++ in a main process that doesn’t also need
C++. You can work around it with LD_PRELOAD. This should be fixed in 6.3.0,
although I have no tested it recently.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Excellent!
That’ll work just fine for now 
/Johan
“Chris McKillop” <cdm@qnx.com> skrev i meddelandet
news:bvtsc9$aro$3@inn.qnx.com…
The backtrace is a bit different depending if I use dinkum or gnustdc++.
using dinkum the backtrace is something like this (Sorry, doing this at
another computer)
_dlclose,_fini,_btext,“global destructors keyed to
std::ios_base::Init::_Init_cnt”, 0xXXXX
Anyone know what might be causing this?
The dll is a plugin for the MMedia Framework so changing the dlopen is
not
possible…
Yeah, it has to do with when the shlib’s get unopened. Basically you
cannot
dlopen() a shlib that needs C++ in a main process that doesn’t also need
C++. You can work around it with LD_PRELOAD. This should be fixed in
6.3.0,
although I have no tested it recently.
chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/