Re: shared libs: is it (whose?) bug?

[hjl@lucon.org (H.J. Lu)]

> 
> This is a multi-part message in MIME format.
> --------------CEA469D2E2242C384C91E432
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> I hope this isn't old territory, but I don't even have a clue
> for a search key on archives that wouldn't give me too much,
> given that I haven't seen this discussed.
> 
> I'm not sure whether this even is a bug, and if so, whose.
> There definitely is a behavior difference between various
> versions of ld, and it's arguable which is "right".
> 
> When using shared libraries, and using the Solaris linker,
> it is possible for a dynamically loaded (using dlopen())
> shared library to call back to the main executable, to an
> entry point that was not mentioned as a dynamic symbol
> at link time (details below).  Using the gnu ld, this
> is not possible due to dynamic symbol table issues.
> I've attached a small test case that shows the failure in detail.
> 

# uname
Linux
# make
gcc --shared -o dynfunc.so dynfunc.c
gcc -rdynamic -o t1 t1.c -ldl
# ./t1
In function dynfunc() '3' was passed in
called from loaded module

You can also use

# gcc -Wl,-export-dynamic -o t1 t1.c -ldl



H.J.