Bug in installation procedure

[Mark Mitchell <mark at codesourcery dot com>]

This is cute.  See how we install libgcc.a, etc.:

	  $(INSTALL_DATA) libgcc.a $(libsubdir)/libgcc.a; \
	  if $(RANLIB_TEST_FOR_TARGET) ; then \
	    (cd $(libsubdir); $(RANLIB_FOR_TARGET) libgcc.a); else true; fi; \
	  chmod a-x $(libsubdir)/libgcc.a; \

On Linux, at least, `ranlib' changes the mode on the file.  (I guess
it creates the file anew, or some such.)  In any case, one's umask
comes into play, even though INSTALL_DATA explicitly sets permissions.

The result is that on a RH6.1 system, with no tweaks to the `root'
account, doing a `make install' as root yields:

-rw-r--r--   1 root     root         1420 Feb 17 14:57 crtend.o
-rw-r--r--   1 root     root         1624 Feb 17 14:57 crtendS.o
-rwxr-xr-x   1 root     root      6428294 Feb 17 14:57 f771
-rwxr-xr-x   1 root     root        68946 Feb 17 14:57 jvgenmain
-rw-rw----   1 root     root       755078 Feb 17 14:59 libchill.a
-rw-rw----   1 root     root      2548732 Feb 17 14:59 libg2c.a
...

Note how everything is world readable except the libraries.  Major
user confusion ensues.  At least I was majorly confused when I saw:

gandalf.codesourcery.com% gcc test.c
/usr/bin/ld: cannot open -lgcc: No such file or directory
collect2: ld returned 1 exit status

Any ideas on how to fix this mess?  (It would be a lot easier if the
RANLIB_FOR_TARGET stuff wasn't duplicated everywhere.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com