Shared library annoyance with gcc-3_0-branch

[Joseph S. Myers]

On Mon, 19 Feb 2001, H . J . Lu wrote:

> It is a good start. But it is a very bad idea to have
> 
> lrwxrwxrwx    1 hjl      hjl            13 Feb 19 16:02 libgcc_s.so -> libgcc_s.so.0
> -rw-r--r--    1 hjl      hjl        180260 Feb 19 04:14 libgcc_s.so.0
> 
> 
> Please remember when you install/untar libgcc_s.so.0 like this, you may
> overide an libgcc_s.so.0 which is being used other processes. One way
> to get around it is to have something like
> 
> lrwxrwxrwx    1 hjl      hjl            13 Feb 19 16:02 libgcc_s.so -> libgcc_s.so.0
> lrwxrwxrwx    1 hjl      hjl            13 Feb 19 16:02 libgcc_s.so.0 -> libgcc-3.0-20010219.so
> -rw-r--r--    1 hjl      hjl        180260 Feb 19 04:14 libgcc-3.0-20010219.so

Doing an install by untarring to the installed name is fundamentally
dangerous.  Any system that works for installing libc at present will need
to use temporary names and renaming.

GNU libc does the right thing when installing from source; GCC needs to do
something similar.  At present, I'm not convinced it does.  The test is
somewhat complicated and would best be done in a chroot on a GNU/Linux
system; I haven't tried it:

* Install GCC 3 branch as the system compiler (or, at least, with shared
libgcc in /lib).

* Recompile the system glibc with this GCC, and install the resulting
glibc which depends on the shared libgcc.  At this point we'd be in
approximately the situation of
<URL: http://gcc.gnu.org/ml/gcc/2001-02/msg00591.html >, except that with
libgcc in /lib the system should still boot.

* Rebuild GCC 3 (again, with --with-slibdir=/lib) and install from source
with "make install".  See if the process completes.

Why I think this might not work: for some reason, the toplevel Makefile.in
forces the use of the shell script install-sh rather than a system C
program install.  config/t-linux has

	$(INSTALL_DATA) @shlib_base_name@.so $$(slibdir)/@shlib_base_name@.so.0

The soname is @shlib_base_name@.so.0.  The install-sh script finishes the
install with (having copied to a temporary file)

        $doit $rmcmd -f $dstdir/$dstfile &&
        $doit $mvcmd $dsttmp $dstdir/$dstfile 

But, after removing the destination file name, libgcc_s.so.0 would be
missing - so the mv, linked against the shared libc and so the shared
libgcc, would fail.

It is necessary to ensure that the soname is available, and points to a
valid (new or old) shared libgcc, at all times during the install.

-- 
Joseph S. Myers
jsm28@cam.ac.uk