This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Handle the shared libgcc is a system library
On Sun, Jul 01, 2001 at 06:52:40PM -0700, Geoff Keating wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
>
> > On Sun, Jul 01, 2001 at 05:57:26PM -0700, Geoff Keating wrote:
> >
> > > It should be mentioned at this point that we cannot promise binary
> > > compatibility between _snapshots_. It might turn out that a new
> > > function, is added, is found to be a mistake, and is then removed.
> > >
> >
> > That is the whole point. By installing libgcc_s.so as
> > libgcc_s-`gcc --release`.so, you won't override the existing
> > libgcc_s.so. The befinits are
> >
> > 1. A libgcc_s.so.1 is always available at any time.
> > 2. You can go back the to the old one if the new one
> > turns out to be bad :-(.
>
> I'm not sure you mean.
>
> I agree that libgcc_s should be installed like glibc installs its
> libraries:
>
> -rwxr-xr-x 60915 /lib/libutil-2.2.2.so
> lrwxrwxrwx 16 /lib/libutil.so.1 -> libutil-2.2.2.so
> lrwxrwxrwx 22 /usr/lib/libutil.so -> ../../lib/libutil.so.1
>
> But if you just install another, say 'libutil-2.2.3.so', that does
> nothing until the symlinks are changed. ld.so will ignore it. If the
> new library is essential to run programs with the new compiler,
> they will not work.
Just following what you said, "like glibc installs its libraries", in
glibc, we do
# ldconfig
as the last step. At that time, the magic thing happens. That is now
you have
/lib/libutil.so.1 -> libutil-2.2.3.so
In gcc, if we can't assume ldconfig is available, we can do
# ln -sf libgcc_s-xxxxx.so libgcc_s.so.1
If we cann't even assume `ln -sf' works, I think sln from glibc can do
the job. FYI, sln is a small program I wrote to make symlinks. It is
compiled as a static binary.
H.J.