Re: An ELF linker patch

[Ian Lance Taylor <ian@cygnus.com>]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 30 Apr 1998 11:53:55 -0700 (PDT)

   This patch fixes the bug with

   # gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic

   under glibc 2.1. The problem is there are some data symbols defined in
   both the dynamic linker as well as libc.a under glibc 2.1. When
   -Wl,-Bstatic is added at the end, the dynamic linker and libc.a are
   used for the final link. As the result, those data symbols are defined
   in the dynamic executable. But when it runs, the dynamic linker will
   be invoked by the kernel to load the dynamic executable. During the
   loading, the data symbol definitions in the dynamic linker are used.
   But after switching to the executable, the definitions in the executable
   are used. It doesn't work very well since the dynamic linker depends on
   those data symbols very much.

   This patch seems to fix the problem by loading the dynamic linker first
   before anything else such that the definitions in libc.a are not used
   if the dynamic linker presents.

It's not correct in general to link against the dynamic linker, so I
don't think this patch is correct.  Moreover, even if it were correct,
it would only work when using the --dynamic-linker option, so it is
fragile.  Moreover, it is clearly wrong when cross linking.

If you are trying to solve a problem specific to the glibc build
process, why not change the above line to explicitly link against the
dynamic linker?

If you are trying to solve a more general problem, then it seems that
there must be magic symbols in the dynamic linker.  Your bug report
lacks specific information, but I don't see how this could arise in
any other way.  If there are magic symbols in the dynamic linker, then
I would suggest that the dynamic linker handle them magically.

Perhaps if you provide some more specific information, like what the
actual bug is, I can suggest a different way to address the problem.

Ian