Shared library question
H. J. Lu
hjl@lucon.org
Thu Jul 18 12:01:00 GMT 2002
On Thu, Jul 18, 2002 at 08:09:02PM +0400, Zagorodnev, Grigory wrote:
> >> Actually I found the reason and made the fix for _my_particular_case. But
> it
> >> seems to be a linker bug. Should it be reflected in separate report or
> not?
> >
> >Please provide a small testcase to show the bug. I will look into it.
>
> Given test case reproduces the _desired_ situation: 'old' application is
> still running, new - could not be built. You should see final 'PASSED'
> message.
>
> Now, if you uncomment marked line in the version.map file and run the test
> again, you will see the failure: 'old' application is unable to run.
> And, of cource you will not see 'PASSED' message.
>
> Note: just run make.
>
Your Makefile is wrong.
LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH); a.out
is not the same as
LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH) a.out
After fixing that, I got
# make
- Build the 'old' library first
gcc -shared -Wl,-soname=libfoo.so -o libfoo.so libfoo.c
- Next, build the application linked against it
gcc main.c -L. -lfoo
- Make sure that it runs (you should see 'foo is there' message)
foo is there
- Now build the 'new' library
gcc -shared -DLIB_X -Wl,-soname=libfoo.so -o libfoo.so libfoo.c
-Wl,--version-script,version.map
- Make sure that the application is still runable
foo is there
- Now try build application linked against 'new' library
(you should see unresolved reference message)
gcc main.c -L. -lfoo 2>/dev/null
make: [all] Error 1 (ignored)
- PASSED
BTW, there was a bug in glibc, which would cause your problem. It was
fixed by
2002-04-02 Ulrich Drepper <drepper@redhat.com>
* elf/do-lookup.h (do_lookup): 2 is the first user-defined version
number [PR libc/3111].
Please make sure your glibc is ok.
H.J.
More information about the Binutils
mailing list