proposed spec file patch for java / 2.95

[Tom Tromey <tromey at cygnus dot com>]

The appended patch fixes a critical bug for the java front end.  We
(the java hackers) would like it to go onto the 2.95 branch.

Some background: the Java runtime supplies a specs file (which is read
in addition to the standard specs file) that lists all the libraries
required by default when linking a Java application.  The Java front
end reads this specs file when it determines that the user is trying
to link a program.  In the ordinary case it does this by adding
`-specs=libgcj.spec' to the command line via lang_specific_driver().

However, we recently changed libgcj so that the libraries would be
installed in libdir when doing a native build (we still use tooldir
for cross compiles).  This seems to follow what other libraries do,
and it also seems like the right thing to do.

However, gcc does not currently search libdir for user-specified specs
files.  There is a comment about this in gcc.c, but it isn't very
helpful:

  /* If not cross-compiling, look for startfiles in the standard places.  */
  /* The fact that these are done here, after reading the specs file,
     means that it cannot be found in these directories.
     But that's okay.  It should never be there anyway.  */

(The `It' in the last sentence makes me suspect that this comment
predates the `-specs' option, but I haven't done any archaeology to
see for sure.)

Without a change, a native `gcj' cannot link a java program as it
cannot find libgcj.spec.  This is why we think the bug is critical.

This patch doesn't seem very risky to me, but I'll admit I don't know
all the subtle ways specs might interact with startfile_prefixes.

For the record, there are other ways to fix this, but they are either
much more complicated (e.g., compute libdir from GCC_EXEC_PREFIX a
second time, in jvspec.c) or hacky (install the libgcj spec file
somewhere other than where we install the library).

Tom

1999-06-22  Tom Tromey  <tromey@cygnus.com>

	* gcc.c (main): Read user-specified specs files after computing
	additional startfile_prefixes.

Index: gcc.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/gcc.c,v
retrieving revision 1.257
diff -u -r1.257 gcc.c
--- gcc.c	1999/06/21 22:30:09	1.257
+++ gcc.c	1999/06/22 19:58:48
@@ -5246,18 +5246,7 @@
   if (access (specs_file, R_OK) == 0)
     read_specs (specs_file, TRUE);
  
-  /* Process any user specified specs in the order given on the command
-     line.  */
-  for (uptr = user_specs_head; uptr; uptr = uptr->next)
-    {
-      char *filename = find_a_file (&startfile_prefixes, uptr->filename, R_OK);
-      read_specs (filename ? filename : uptr->filename, FALSE);
-    }
-
   /* If not cross-compiling, look for startfiles in the standard places.  */
-  /* The fact that these are done here, after reading the specs file,
-     means that it cannot be found in these directories.
-     But that's okay.  It should never be there anyway.  */
   if (*cross_compile == '0')
     {
 #ifdef MD_EXEC_PREFIX
@@ -5318,6 +5307,14 @@
 		    concat (gcc_exec_prefix, machine_suffix,
 			    standard_startfile_prefix, NULL_PTR),
 		    "BINUTILS", 0, 0, NULL_PTR);
+    }
+
+  /* Process any user specified specs in the order given on the command
+     line.  */
+  for (uptr = user_specs_head; uptr; uptr = uptr->next)
+    {
+      char *filename = find_a_file (&startfile_prefixes, uptr->filename, R_OK);
+      read_specs (filename ? filename : uptr->filename, FALSE);
     }
 
   /* If we have a GCC_EXEC_PREFIX envvar, modify it for cpp's sake.  */