This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
- From: Richard Biener <rguenther at suse dot de>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, tromey at redhat dot com, sandra at codesourcery dot com
- Date: Wed, 19 Feb 2014 10:34:39 +0100 (CET)
- Subject: Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1402181415520 dot 1593 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1402191001470 dot 1593 at zhemvz dot fhfr dot qr> <53047906 dot 6060205 at redhat dot com>
On Wed, 19 Feb 2014, Andrew Haley wrote:
> On 02/19/2014 09:03 AM, Richard Biener wrote:
> > On Tue, 18 Feb 2014, Richard Biener wrote:
> >
> >>
> >> The following two pieces fix the fallout of
> >>
> >> 2013-05-22 Mark Mitchell <mark@codesourcery.com>
> >> Sandra Loosemore <sandra@codesourcery.com>
> >>
> >> * configure.ac (dbexecdir): Base on $(toolexeclibdir), not
> >> $(libdir).
> >> ...
> >>
> >> that makes a wreck out of my 4.9-based libjava installs.
> >>
> >> First it avoids to break dbexecdir with MULTSUBDIR= by removing
> >> the redundant but non-version-specific-aware multilib addition.
> >>
> >> Second, it makes sure that gcc_version, used in the
> >> version-specific path, is defined at all in classpath/ and its
> >> subdirs.
> >>
> >> Tested for my particular configuration, I'll do a default,
> >> non-version-specific one as well (but expect no changes).
> >>
> >> Ok for trunk?
> >
> > In addition to my weird non-multilib version-specific variant
> > I now tested regular non-version-specific and multilib variant
> > as well as version-specific multilib variant and all looks ok.
> >
> > Thus,
> >
> > Ok for trunk?
>
> It may be that someone understands this, but I don't. What does this change
> do?
It fixes breakage introduced by Sandras patch. In particular it avoids
libjava to end up in random places:
/usr/lib64/gcc/x86_64-suse-linux/
4.9 gcj-4.9-15 lib64 logging.properties security
/usr/lib64/gcc/x86_64-suse-linux/4.9/
ecj.jar include jvgenmain libgcj.la libgcj.spec libgij.so
ecj1 jc1 libgcj-tools.so libgcj.so libgcj_bc.so pkgconfig
/usr/lib64/gcc/x86_64-suse-linux/gcj-4.9-15/
libjavamath.la libjavamath.so
/usr/lib64/gcc/x86_64-suse-linux/lib64/gcj-4.9-15
classmap.db libjvm.la libjvm.so
and changes that to
/usr/lib64/gcc/x86_64-suse-linux/4.9/
ecj.jar include jvgenmain libgcj.la libgcj.spec libgij.so
ecj1 jc1 libgcj-tools.so libgcj.so libgcj_bc.so pkgconfig
gcj-4.9-15 logging.properties security
/usr/lib64/gcc/x86_64-suse-linux/4.9/gcj-4.9-15
classmap.db libjvm.la libjvm.so libjavamath.la libjavamath.so
for --enable-version-specific-runtime-libs (no changes for without
that option). Sandras patch was supposed to introduce support
for --enable-version-specific-runtime-libs in libgcj (but obviously
it failed, given the result above).
With multilibs there is a 2nd gcj-4.9-15 inside
/usr/lib64/gcc/x86_64-suse-linux/4.9/32/ with the patch.
Hope this helps.
Thanks,
Richard.