proposed spec file patch for java / 2.95

[Jeffrey A Law]

  In message < 87iu8fzdqn.fsf@cygnus.com >you write:
  > 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().
OK.  I'm already a little familiar with this since I had a bear of a time
trying to find out where the reference to this file came from when I was
trying to build/test libgjc.

To work around the problem I made copies of the file in all the important
directories I could think of.  Certainly not the most elegant solution to
the problem, but effective for what I needed to do :-)


  > 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.
Right.

  > 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:
So, I'm curious, we do search libsubdir and tooldir, right?  What mechanism
are we using to have those directories searched?  Shouldn't we use the same
means to specify that libdir should be searched for spec files too.

[ Maybe that's what your patch does, if so, say so :-) I get the feeling that
  may be what you're doing, a confirmation would be good.  ]


  > (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.)
It's quite possible -specs is fairly new and is not used by a huge number
of targets (the rtems targets are the biggest users of -specs= option.


  > 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.
I agree :-)


  > 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.
That's what worries me to.


  > 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).
Ewwww.  Hmmm, so the spec file is part of the library.  Yup, that does
make it more difficult to install it in libsubdir.

What's the rationale behind having the specfile in the library and not
provided by the compiler?


jeff