Symbol resolution in shared libs.

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I wrote a shared lib containing a function calling initResmgr().
This initResmgr() belongs to shared lib.
When I objdump the lib, I can see.
…
xxxxxxxx g F .text xxxxxxxx initResmgr
…

Meanning AFAK that initResmgr() is RESOLVED.

I have in the main executable another initResmgr function.

When I execute the main, it calls the lib’s function calling
initResmgr() but, the executed initResmgr() is the one belonging to the
main executable and not the one belonging to the lib.

I don’t understand that. Why a resolved symbol in the lib has been
RElinked to another one existing in the executable? Could you clarly
explain me that point?

I try to use the -Bsymbolic flag to make the lib. I don’t know if there
is something to see with this problem but it didn’t solve it.

Thanks,
Alain.

2

Alain Bonnefoy a écrit :

I wrote a shared lib containing a function calling initResmgr().
This initResmgr() belongs to shared lib.
When I objdump the lib, I can see.
…
xxxxxxxx g F .text xxxxxxxx initResmgr
…

Meanning AFAK that initResmgr() is RESOLVED.

I have in the main executable another initResmgr function.

When I execute the main, it calls the lib’s function calling
initResmgr() but, the executed initResmgr() is the one belonging to the
main executable and not the one belonging to the lib.

I don’t understand that. Why a resolved symbol in the lib has been
RElinked to another one existing in the executable? Could you clarly
explain me that point?

I try to use the -Bsymbolic flag to make the lib. I don’t know if there
is something to see with this problem but it didn’t solve it.

Thanks,
Alain.

-Bsymbolic works in fact, but gives a warning for each of the not resolved
symbols in the lib.
Not cool as I don’t really like warnings!

Thanks,
Alain.

3

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
…

I don’t understand that. Why a resolved symbol in the lib has been
RElinked to another one existing in the executable? Could you clarly
explain me that point?
…

This lets you define your own malloc() and free() in the executable, and
be sure that nothing will use the default ones.

Another explanation is that this behaviour is consistent with how static
libraries work…

–
Wojtek Lerch QNX Software Systems Ltd.

4

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

I wrote a shared lib containing a function calling initResmgr().
This initResmgr() belongs to shared lib.
When I objdump the lib, I can see.
…
xxxxxxxx g F .text xxxxxxxx initResmgr
…

Meanning AFAK that initResmgr() is RESOLVED.

I have in the main executable another initResmgr function.

When I execute the main, it calls the lib’s function calling
initResmgr() but, the executed initResmgr() is the one belonging to the
main executable and not the one belonging to the lib.

I don’t understand that. Why a resolved symbol in the lib has been
RElinked to another one existing in the executable? Could you clarly
explain me that point?

I try to use the -Bsymbolic flag to make the lib. I don’t know if there
is something to see with this problem but it didn’t solve it.

All function calls in a shared object are done indirectly, via the
Procedure Linkage Table (PLT) and Global Offset Table (GOT)

When you load a shared object, for each entry in the procedure table,
the dynamic linker searches for the symbol in the symbol tables already
loaded, and then patches the PLT appropriately.

The default is to look in the executable first, unless the shared
object was linked with -Bsymbolic.

You can also affect the symbol resolution with the flags passed to
dlopen() - read the man page for that for more information.

–
cburgess@qnx.com