libjvm.la and problems with libtool relink mode

[Mark Shinwell <shinwell at codesourcery dot com>]

I am currently involved in building GCC toolchains by configuring them with
the prefix that is to be used on the target system (somewhere in /opt)
and then installing them in a separate "working installation" directory
(say somewhere in my scratch space).  The installation step into this
"working installation" directory is performed by invoking a command of
the form "make prefix=/path/to/working/dir/install install".

Unfortunately it seems that, when using current mainline and building
for native x86_64, there is an awkward problem involving the building
of libjvm.la.  This libtool file is built from two others: one .lo file
and one .la file.  The difficulty arises at the libtool "install" step
for libjvm.la.  It seems that since the "link" command that constructed
libjvm.la built that library using another .la file (libgcj.la) then
libtool writes a relink command into the libjvm.la file.  Then, when
installing libjvm.la using libtool, it attempts to execute that relink
command.  This however fails because the installation location is not
a subdirectory of the configured prefix -- it is somewhere completely
different.  This piece of libtool code causes the error:

          # Don't allow the user to place us outside of our expected
          # location b/c this prevents finding dependent libraries that
          # are installed to the same prefix.
          # At present, this check doesn't affect windows .dll's that
          # are installed into $libdir/../bin (currently, that works fine)
          # but it's something to keep an eye on.
          if test "$inst_prefix_dir" = "$destdir"; then
            $echo "$modename: error: cannot install \`$file' to a directory not 
ending in $libdir" 1>&2
            exit 1
          fi

This problem does not arise with various other .la files created during
the build process of gcc (such as libstdc++.la for example) because those
are directly created from a bunch of .lo files; none of them were built
from another .la as libjvm.la is.

The writing of the relink command into libjvm.la comes as a result of
"need_relink=yes" on line 2095 of the ltmain.sh in the toplevel directory
of mainline gcc.  I wonder if this assignment ought to be guarded
by a test involving $hardcode_into_libs, which is currently set to "yes" in
my generated <builddir>/x86_64-unknown-linux-gnu/libjava/libtool.
Perhaps I should be having $hardcode_into_libs set to "no" in addition to
changing the libtool code so that need_relink is only set to "yes" if
$hardcode_into_libs is set to "yes" also?  The exact behaviour of the
two modes of $hardcode_into_libs isn't clear to me, however, so I'm not
very sure.  With that "solution" I'm also assuming that libtool is doing
the right thing in forcing a relink in this situation (if $hardcode_into_libs
is "yes"); perhaps even that isn't the case.

If anyone could offer any advice as to how to proceed here, I'd be most
grateful.  I've copied this to Alexandre since a colleague suggested he
might know the answer :-)

Mark