[committed] Fix IRIX fallout from Solaris mklibgcc changes

[Richard Sandiford <rsandifo at redhat dot com>]

[ cc'ing folks involved in the original mklibgcc threads, and David B.,
  who provides regular IRIX results. ]

As reported a few weeks ago, the Solaris mklibgcc changes broke
execution testing for the non-default IRIX multilibs.  The full
horror can be seen from results like:

    http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg01064.html

Discussion of the problem was here:

    http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00570.html
    http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00574.html
    http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00577.html

but the thread went cold without the supporters of the Solaris
changes suggesting how this should be fixed in general (i.e.,
without invalidating the original objective of the changes).

Given the effect that these changes had -- and the fact that they
were made in stage 3 -- I suppose one alternative would be to revert
the patches and go back to the old scheme.  There was at least one
message from David Edelsohn in support of the original set-up:

     http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00192.html

but I don't know if that's still his position.

Assuming that going back to the old scheme isn't an option, the patch
below at least gets IRIX back to normal.  I'm happy to revert it and
do something else if there's concensus on what the something should be.

To recap, the build directory (gcc/) used to be laid out like this:

    libgcc_s.so.1               (soname libgcc_s.so.1)
    mabi-32/libgcc_s.so.1       (soname libgcc_s.so.1)
    mabi-64/libgcc_s.so.1       (soname libgcc_s.so.1)

    libgcc_s.so -> libgcc_s.so.1
    libgcc_s_mabi-32.so -> mabi-32/libgcc_s.so.1
    libgcc_s_mabi-64.so -> mabi-64/libgcc_s.so.1

where mabi-32 and mabi-64 are the MULTILIB_DIRNAMES directories
for -mabi=32 and -mabi=64 respectively.  gcc would link against the
multilib-encoded *.so files and the testsuite would add the appropriate
MULTILIB_DIRNAMES directory[*] to LD_LIBRARY_PATH and friends.  Each test
thus found the right version of libgcc_s.so.1 at runtime.

  [*] as opposed to the MULTILIB_OSDIRNAMES directory used by
      the installed tree

For reference, the install directory looked like this:

    libgcc_s.so.1               (soname libgcc_s.so.1)
    mabi=32/libgcc_s.so.1       (soname libgcc_s.so.1)
    mabi=64/libgcc_s.so.1       (soname libgcc_s.so.1)

    libgcc_s.so -> libgcc_s.so.1
    mabi=32/libgcc_s_mabi-32.so -> libgcc_s.so.1
    mabi=64/libgcc_s_mabi-64.so -> libgcc_s.so.1

where mabi=32 and mabi=64 are the MULTILIB_OSDIRNAMES directories
for -mabi=32 and -mabi=64.  This hasn't changed, and the installed
tree still works.

Anyway, the recent mklibgcc patches made the build directory use a
flat layout in which both the DSO and symlink have multilib-encoded
names:

    libgcc_s.so.1               (soname libgcc_s.so.1)
    libgcc_s_mabi-32.so.1       (soname libgcc_s.so.1)
    libgcc_s_mabi-64.so.1       (soname libgcc_s.so.1)

    libgcc_s.so -> libgcc_s.so.1
    libgcc_s_mabi-32.so -> libgcc_s_mabi-32.so.1
    libgcc_s_mabi-64.so -> libgcc_s_mabi-64.so.1

It's therefore not possible to run shared-libgcc o32 and n64 executables
from the build tree because the dynamic loader will try to use the n32
version of libgcc_s.so.1.

It's easy to revert SHLIB_LINK to the old behaviour by changing:

    SHLIB_NAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
to:
    SHLIB_NAME = @multilib_dir@/@shlib_so_name@.so.$(SHLIB_SOVERSION)

in t-slibgcc-irix.  However, @multilib_dir@ isn't available to
SHLIB_INSTALL, and since this patch was always going to be a
band-aid, I wanted something that would only affect IRIX,
not mklibgcc.in.

The patch below therefore keeps the original SHLIB_NAME but gets
SHLIB_LINK to "install" a copy of it as @multilib_dir@/$(SHLIB_SONAME)
(still talking about the bulid tree here).  This copy will then get
used when running the testsuite.

Tested on mips-sgi-irix6.5, applied to head.  I realise that the patch
is a kludge, but it was very difficult to test IRIX stuff with things
as they stood, and I wanted to fix that ASAP.  Like I say, I'm happy
to revisit this if there's consensus on what the Right Way is.

Richard


	* config/mips/t-slibgcc-irix (SHLIB_LINK): Install a copy of the
	library as @multilib_dir@/$(SHLIB_SONAME).

Index: config/mips/t-slibgcc-irix
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/mips/t-slibgcc-irix,v
retrieving revision 1.4
diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.4 t-slibgcc-irix
--- config/mips/t-slibgcc-irix	16 Dec 2004 19:14:28 -0000	1.4
+++ config/mips/t-slibgcc-irix	8 Jan 2005 10:43:34 -0000
@@ -18,7 +18,9 @@ SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2
 	  mv -f $(SHLIB_NAME) $(SHLIB_NAME).backup; \
 	else true; fi && \
 	mv $(SHLIB_NAME).tmp $(SHLIB_NAME) && \
-	$(LN_S) $(SHLIB_NAME) $(SHLIB_SOLINK)
+	$(LN_S) $(SHLIB_NAME) $(SHLIB_SOLINK) && \
+	{ test "@multilib_dir@" = "." || \
+	  $(INSTALL_DATA) $(SHLIB_NAME) @multilib_dir@/$(SHLIB_SONAME); }
 # $(slibdir) double quoted to protect it from expansion while building
 # libgcc.mk.  We want this delayed until actual install time.
 SHLIB_INSTALL = \