This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
On Wed, Feb 21, 2001 at 10:44:04PM -0800, Zack Weinberg wrote:
> >
> > The ELF dynamic linker doesn't work this way. It will use the first
> > DSO with the right soname. You just have to make sure the right DSO
> > is found by the dynamic linker. With libc.so, we only have one in
> > /lib.
>
> If we add symbols to libgcc_s.so, they will have a different symbol
> version (GCC_3.1 or something). The dynamic linker will be faced with
>
> binary uses: GCC_3.0 GCC_3.1
> /lib/libgcc_s.so: GCC_3.0
> /path/to/other/lib/libgcc_s.so: GCC_3.0 GCC_3.1
>
> I don't know if it is intelligent enough, in this context, to link
> only the libgcc_s.so in /path/to/other/lib. However, it will pick one
ld.so will pick the first one it finds. Without LD_LIBRARY_PATH, it
will use /lib/libgcc_s.so.
> or the other, and the worst that happens is an undefined symbol
> error. Then the user has to set LD_LIBRARY_PATH.
In general, the user has to set LD_LIBRARY_PATH to get libgcc_s.so in
/path/to/other/lib. But when he/she does that, every single binary
she/he runs, including 'ls', will use /path/to/other/lib/libgcc_s.so.
As I said before, it is the same as having 2 libc.so. Please remember
now you have replaced a system library in /lib. Even if you use -rpath,
which I don't like, it will means all DSOs, including those come with
the system, opened by the new binary will use the new libgcc_s.so in
/path/to/other/lib. Do you think it is safe to do so? If yes, why not
put the new libgcc_s.so in /lib?
>
> [IMO, if it were to link _both_, that would be a bug.]
It shouldn't happen since both should have the same soname.
--
H.J. Lu (hjl@valinux.com)