Using dlopen() in PhAb project

QNX Newsgroups (Archives) qnx.cafe
1

Hello,
I’m having a little difficulty using dlopen() from my PhAb project.
I’ve created my library like so:

gcc -shared -fPIC -c -I/home/gman/Projects/C -I.
/home/gman/Projects/Plugins/test_plugin.c -o /home/gman/test.so

it compiles no problems.

And have opened it using dlopen, like so:

so_handle = dlopen((const char *) “/home/gman/test.so”,RTLD_NOW);

But dlopen returns a NULL pointer and dlerror() reports:

dlopen error: Shared library is corrupted

Do I have to make my entire PhAb program a dynamically linked program?
If so, how?

Thanks a lot

Garry

2

You are only compiling it (because of the -c option)

So it is still only a .o file, even though you are telling qcc to call
it a .so

Garry wrote:

Hello,
I’m having a little difficulty using dlopen() from my PhAb project.
I’ve created my library like so:

gcc -shared -fPIC -c -I/home/gman/Projects/C -I.
/home/gman/Projects/Plugins/test_plugin.c -o /home/gman/test.so

it compiles no problems.

And have opened it using dlopen, like so:

so_handle = dlopen((const char *) “/home/gman/test.so”,RTLD_NOW);

But dlopen returns a NULL pointer and dlerror() reports:

dlopen error: Shared library is corrupted

Do I have to make my entire PhAb program a dynamically linked program?
If so, how?

Thanks a lot

Garry

–
cburgess@qnx.com

3

Put your gmalloc in a utility shared lib, and link your executable and
your shared lib against it.

Garry wrote:

Colin Burgess wrote:

You are only compiling it (because of the -c option)

So it is still only a .o file, even though you are telling qcc to call
it a .so


Doh! I took that away and it’s OK now. Thanks.

Just one more thing, from within my shared object, I cannot access
functions which are available from outside the shared object, but in the
same process. i.e. I’ve got my own gmalloc() call, which I use to debug
my mallocs, I can use it anywhere in my program, except in the shared
object, although printf() does work.

Thanks again.

Garry

–
cburgess@qnx.com

4

Colin Burgess wrote:

You are only compiling it (because of the -c option)

So it is still only a .o file, even though you are telling qcc to call
it a .so

Doh! I took that away and it’s OK now. Thanks.

Just one more thing, from within my shared object, I cannot access
functions which are available from outside the shared object, but in the
same process. i.e. I’ve got my own gmalloc() call, which I use to debug
my mallocs, I can use it anywhere in my program, except in the shared
object, although printf() does work.

Thanks again.

Garry

5

Colin Burgess wrote:

Put your gmalloc in a utility shared lib, and link your executable and
your shared lib against it.

Garry wrote:

Colin Burgess wrote:

You are only compiling it (because of the -c option)

So it is still only a .o file, even though you are telling qcc to
call it a .so


Doh! I took that away and it’s OK now. Thanks.

Just one more thing, from within my shared object, I cannot access
functions which are available from outside the shared object, but in
the same process. i.e. I’ve got my own gmalloc() call, which I use to
debug my mallocs, I can use it anywhere in my program, except in the
shared object, although printf() does work.

Thanks again.

Garry

Thank you again Colin, it’s working great now.

Garry