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 11:18:33PM -0800, H . J . Lu wrote:
> 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.
Shouldn't it reject /lib/libgcc_s.so and continue searching in hopes
of finding a newer library somewhere else? This is a serious question.
> > 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?
The hard-line statement is: if it isn't safe, that is a bug.
However, there are degrees of perceived safety. I might feel
comfortable running my entire account with the new libgcc_s.so, but
not comfortable causing the system daemons to use it too. I might
have set up a special sandboxed user for test purposes.
Also consider the case of an unprivileged user installing gcc in their
own account. They don't put it in /lib because they can't.
zw