[Bug java/60261] New: [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[Bug java/60261] New: [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

            Bug ID: 60261
           Summary: [4.9 Regression] Weird java install with
                    --enable-version-specific-runtime-libs
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: java
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

I get in

/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

not sure what happens without --enable-version-specific-runtime-libs.

Behaved "more sanely" with 4.8, everything under /usr/lib64/gcj-4.8-14/
(I also have --program-suffix=4.x)

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at codesourcery dot com
   Target Milestone|---                         |4.9.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Suspect

2013-05-22  Mark Mitchell  <mark@codesourcery.com>
            Sandra Loosemore  <sandra@codesourcery.com>

        * configure.ac (dbexecdir): Base on $(toolexeclibdir), not
        $(libdir).
        * Makefile.am (pkgconfigdir): Likewise.
        * configure: Regenerated.
        * Makefile.in: Regenerated.
        * gcj/Makefile.in: Regenerated.
        * include/Makefile.in: Regenerated.
        * testsuite/Makefile.in: Regenerated.

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
In particular

   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir

doesn't seem to work as $multi_os_directory contains a '..'.  I get:



toolexecdir = $(libdir)/gcc/$(target_noncanonical)
toolexeclibdir = $(toolexecdir)/$(gcc_version)$(MULTISUBDIR)
toolexecmainlibdir = $(toolexecdir)/$(gcc_version)$(MULTISUBDIR)

dbexecdir = $(toolexeclibdir)/../lib64/gcj-4.9-15

So the simple s/libdir/toolexeclibdir/ doesn't work and/or doesn't make sense
(note I also disable multilibs - but just in libjava, so I get MULTISUBDIR=)

Shouldn't dbexecdir just use $(MULTISUBDIR)?

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
libjavamath uses

nativeexeclib_LTLIBRARIES = libjavamath.la

and inside classpath

             nativeexeclibdir='${toolexeclibdir}/gcj-'`cat
${srcdir}/../../gcc/BASE-VER`-`awk -F: '/^[[^#]].*:/ { print $1 }'
${srcdir}/../libtool-version`

(eh)

thus not multilib aware.  4.8 put the gcj-4.8 dir in /usr/lib64/, thus not
aware of version-specific dirs and it contained

classmap.db  libjavamath.la  libjavamath.so  libjvm.la  libjvm.so

Why wasn't that "version-specific" enough?  (it has the -sover suffix?)
If it wasn't enough the whole stuff should be below
/usr/lib64/gcc/x86_64-suse-linux/4.9/ which means both path variants used
by 4.9 currently are bogus.

I think given the current state of libjava maintainance reverting the
change is the best.

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, it seems to me that

# Determine where the standard .db file and GNU Classpath JNI
# libraries are found.
gcjsubdir=gcj-$gcjversion-$libgcj_soversion
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
  .)
   dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
   ;;
  *)
   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
   ;;
esac

is simply "duplicate", toolexeclibdir is already properly containing the
multilib.  Thus,

Index: libjava/configure.ac
===================================================================
--- libjava/configure.ac        (revision 207837)
+++ libjava/configure.ac        (working copy)
@@ -1596,15 +1596,7 @@ AC_DEFINE_UNQUOTED(GCJVERSION, "$GCJVERS
 # Determine where the standard .db file and GNU Classpath JNI
 # libraries are found.
 gcjsubdir=gcj-$gcjversion-$libgcj_soversion
-multi_os_directory=`$CC -print-multi-os-directory`
-case $multi_os_directory in
-  .)
-   dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
-   ;;
-  *)
-   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
-   ;;
-esac
+dbexecdir='$(toolexeclibdir)/'$gcjsubdir
 AC_SUBST(dbexecdir)
 AC_SUBST(gcjsubdir)

for dbexecdir?  But that makes it not version-specific again - it lacks
the GCC version suffix?

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Hmm, it seems to me that
> 
> # Determine where the standard .db file and GNU Classpath JNI
> # libraries are found.
> gcjsubdir=gcj-$gcjversion-$libgcj_soversion
> multi_os_directory=`$CC -print-multi-os-directory`
> case $multi_os_directory in
>   .)
>    dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
>    ;;
>   *)
>    dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
>    ;;
> esac
> 
> is simply "duplicate", toolexeclibdir is already properly containing the
> multilib.  Thus,
> 
> Index: libjava/configure.ac
> ===================================================================
> --- libjava/configure.ac        (revision 207837)
> +++ libjava/configure.ac        (working copy)
> @@ -1596,15 +1596,7 @@ AC_DEFINE_UNQUOTED(GCJVERSION, "$GCJVERS
>  # Determine where the standard .db file and GNU Classpath JNI
>  # libraries are found.
>  gcjsubdir=gcj-$gcjversion-$libgcj_soversion
> -multi_os_directory=`$CC -print-multi-os-directory`
> -case $multi_os_directory in
> -  .)
> -   dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
> -   ;;
> -  *)
> -   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
> -   ;;
> -esac
> +dbexecdir='$(toolexeclibdir)/'$gcjsubdir
>  AC_SUBST(dbexecdir)
>  AC_SUBST(gcjsubdir)
>  
> for dbexecdir?  But that makes it not version-specific again - it lacks
> the GCC version suffix?

That makes classmap.db libjvm.la and libjvm.so move to

/usr/lib64/gcc/x86_64-suse-linux/4.9/gcj-4.9-15

which is sensible.  I'm left with

/usr/lib64/gcc/x86_64-suse-linux/
4.9  gcj-4.9-15  logging.properties  security

and

/usr/lib64/gcc/x86_64-suse-linux/gcj-4.9-15/
libjavamath.la  libjavamath.so

For security/logging we have inside classpath/resource/Makefile.am

logging_DATA = java/util/logging/logging.properties
loggingdir = $(toolexeclibdir)

security_DATA = java/security/classpath.security
securitydir = $(toolexeclibdir)/security

so the same issue as with libjavamath - it's missing gcc_version suffix,
so it seems that $(gcc_version) is not defined when building libjava/classpath.

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Trying

Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am (revision 207837)
+++ libjava/Makefile.am (working copy)
@@ -6,6 +6,7 @@ ACLOCAL_AMFLAGS = -I . -I .. -I ../confi

 # May be used by various substitution variables.
 gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+export gcc_version

 SUBDIRS = $(DIRLTDL) gcj include classpath
 if TESTSUBDIR

[Bug java/60261] [4.9 Regression] Weird java install with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.