QNX 6 dlopen problem

Hi,

I have reported a dlopen() problem happens in early QRTP about 1 year ago.
It appears that particular problem has been fixed. However, it has not
been completely fixed.

The problem (I reported one year ago) was dlopen() 2 shared objects with
the same file name stored in different directory. This is fixed if
it uses relative path (my example was using relative path).

The current problem is about dlopen() 2 shared objects with the same file name
but stored in different directory using absolute path. If I use relative
path, it works.

THe version of OS is:
QNX sulfur 6.1.0 2001/08/23-19:38:50edt x86pc x86

In the bottom, I have the shell script to reproduce the problem.
If you cut the shell script and run it, you will see:

Compiling …
Running main …
s=‘this is dll1’
foo1
s=‘this is dll2’
t=‘this is dll2’
foo2
Running main2 … <— This does dlopen ("./dll/…
s=‘this is dll1’
foo1
s=‘this is dll2’
t=‘this is dll2’
foo2
Running main3 … <— This does dlopen ("/tmp/mytest/dll/…
s=‘this is dll1’
foo1
s=‘this is dll1’ <---- this is wrong
Memory fault (core dumped) <---- this core dump



---------------------- start of shell script ---------------------------

QNX 6 dlopen() does not work correctly.

rm -fr /tmp/mytest

mkdir /tmp/mytest

cd /tmp/mytest

cat > main.c <<‘EOM’
#include <stdio.h>
#include <dlfcn.h>

#define NAME1 “/tmp/mytest/dll1.so”
#define NAME2 “/tmp/mytest/dll2.so”

int main ()
{
void* p;
void* pp;
char** str;
void (*func)();


p = dlopen (NAME1, RTLD_NOW | RTLD_LOCAL);
if (p == 0) { printf (“failed to open dll1\n”); return (1); }
str = dlsym (p, “s”);
printf (“s=’%s’\n”, *str);
func = dlsym (p, “foo”);
func();

/* I mean not to dlclose it because my product requires both

  • to be opened
    dlclose (p);
    */

pp = dlopen (NAME2, RTLD_NOW | RTLD_LOCAL);
if (pp == 0) { printf (“failed to open dll2\n”); return (1); }
str = dlsym (pp, “s”);
printf (“s=’%s’\n”, *str);
str = dlsym (pp, “t”);
printf (“t=’%s’\n”, *str);
func = dlsym (pp, “foo”);
func();
dlclose (pp);
return (0);
}
EOM

cat > main2.c <<‘EOM’
#include <stdio.h>
#include <dlfcn.h>

#if FAIL
#define NAME1 “/tmp/mytest/dll1/dll.so”
#define NAME2 “/tmp/mytest/dll2/dll.so”
#else

#define NAME1 “./dll1/dll.so”
#define NAME2 “./dll2/dll.so”
#endif

int main ()
{
void* p;
void* pp;
char** str;
void (*func)();

p = dlopen (NAME1, RTLD_NOW | RTLD_LOCAL);
if (p == 0) { printf (“failed to open dll1\n”); return (1); }
str = dlsym (p, “s”);
printf (“s=’%s’\n”, *str);
func = dlsym (p, “foo”);
func ();

/* I mean not to dlclose it because my product requires both

  • to be opened
    dlclose (p);
    */

pp = dlopen (NAME2, RTLD_NOW | RTLD_LOCAL);
if (pp == 0) { printf (“failed to open dll2\n”); return (1); }
str = dlsym (pp, “s”);
printf (“s=’%s’\n”, *str);
str = dlsym (pp, “t”);
printf (“t=’%s’\n”, *str);
func = dlsym (pp, “foo”);
func ();
dlclose (pp);
return (0);
}
EOM

cat > dll1.c <<‘EOM’
char *s = “this is dll1”;

void foo ()
{
printf (“foo1\n”);
}
EOM

cat > dll2.c <<‘EOM’
char *s = “this is dll2”;
char *t = “this is dll2”;

void foo ()
{
printf (“foo2\n”);
}
EOM

echo “Compiling …”
cc -shared -o dll1.so dll1.c
cc -shared -o dll2.so dll2.c
cc -o main main.c
cc -o main2 main2.c
cc -o main3 -DFAIL main2.c

rm -fr dll1 dll2
mkdir dll1
mkdir dll2
cp dll1.so dll1/dll.so
cp dll2.so dll2/dll.so

echo “Running main …”
…/main
echo “Running main2 …”
…/main2
echo “Running main3 …”
…/main3
---------------------- end of shell script ---------------------------

If you want to check the problem I reported a year ago, look for
‘a serious dlopen problem’ in this newsgroup.


Gordon Man

gman@empress.com wrote:

If you want to check the problem I reported a year ago, look for
‘a serious dlopen problem’ in this newsgroup.

This has been addressed and is fixed in the next release.

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/

thomasf@qnx.com wrote:
: gman@empress.com wrote:
:> If you want to check the problem I reported a year ago, look for
:> ‘a serious dlopen problem’ in this newsgroup.

: This has been addressed and is fixed in the next release.
^^^^

I assume ‘This’ mean the problem in the first post of this thread will
be addressed in the next release.

The problem I reported a year ago has already been addressed in QNX 6.1.0.

Thanks.


Gordon Man
gman@empress.com