[Bug libgcj/38396] New: libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[Bug libgcj/38396] New: libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

If you install libgcj_bc from GCC 4.4 and try to link with GCC 4.3 you get

gcj CaCerts.java --main=CaCerts -o catest
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

gcj: Internal error: Aborted (program ecj1)
Please submit a full bug report.
See <http://bugs.opensuse.org/> for instructions.


-- 
           Summary: libgcj_bc for 4.3 and 4.4 are binary incompatible but
                    have the same SONAME
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: ABI
          Severity: critical
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-12-10 10:35 -------
Testcase (any java program does)

class HelloWorld {
    public static void main(String[] args) {
        String message="Hallo World!";
        System.out.println(message);
    }
}

if you install libgcj_bc from GCC 4.4 (that is, symlink
/usr/lib*/libgcj_bc.so.1
to /usr/lib*/libgcj.so.10 which is from GCC 4.4) then the link fails as
specified, with or without -findirect-dispatch.  This works fine for
GCC 4.2 vs. GCC 4.3.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|libgcj_bc for 4.3 and 4.4   |[4.4 Regression] libgcj_bc
                   |are binary incompatible but |for 4.3 and 4.4 are binary
                   |have the same SONAME        |incompatible but have the
                   |                            |same SONAME
   Target Milestone|---                         |4.4.0


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2008-12-10 10:55 -------
?? libgcj_bc.so.1 isn't supposed to be a symlink to libgcj.so.10, but to
libgcj_bc.so.1.0.0.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-12-10 11:03 -------
Are you sure?  My Debian system agrees with me:

ls -l /usr/lib/libgcj_bc.so.1 
lrwxrwxrwx 1 root root 12 2008-10-01 20:38 /usr/lib/libgcj_bc.so.1 ->
libgcj.so.90

Are the different libgcj not supposed to provide the same indirect dispatch
ABI for all versions?

btw, how does this affect link-time?


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2008-12-10 11:09 -------
-findirect-dispatch compiled/linked programs built with 4.3 work just fine
against 4.4 libgcj_bc.so.1 (that's why libgcj_bc.so.1 was added).
The only problem is if you link a program against both -lgcj_bc and -lgcj,
because if you link say with 4.3, then it will be linked against libgcj_bc.so.1
and libgcj.so.9 and if you then dynamically link it against 4.4 libgcj_bc.so.1,
which depends on libgcj.so.10, both libgcj.so.9 and libgcj.so.10 will be
dynamically linked into the same program, which for obvious reasons can't work
at all (same as for e.g. libstdc++.so.5 and libstdc++.so.6 etc.).

The answer is simple, never link against both -lgcj_bc and -lgcj if you want
the program to work against newer libjava versions.  If a program is
-findirect-dispatch as whole, it should be linked against -lgcj_bc, otherwise
against -lgcj.

This is nothing new, for 4.2 to 4.3 you get exactly the same problems.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at gcc dot gnu dot org


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-12-10 11:12 -------
Ok, it seems that the problem for me is coming from ecj1:

 /usr/lib64/gcc/x86_64-suse-linux/4.3/ecj1 Hello.java -g1
-fbootclasspath=./:/usr/share/java/libgcj-4.3.jar -g1 -fsource=1.5 -ftarget=1.5
-fzip-dependency /tmp/ccMeZbfk.zip -fzip-target /tmp/cca64hlu.jar
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

gcj: Internal error: Aborted (program ecj1)
Please submit a full bug report.
See <http://bugs.opensuse.org/> for instructions.


ldd /usr/lib64/gcc/x86_64-suse-linux/4.3/ecj1
        linux-vdso.so.1 =>  (0x00007ffff7ffc000)
        libgcj.so.9 => /usr/lib64/libgcj.so.9 (0x00007ffff4eb0000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffff4c94000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ffff4a8b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff4887000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ffff4671000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff445a000)
        libgcj_bc.so.1 => /usr/lib64/libgcj_bc.so.1 (0x00007ffff14ea000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff1294000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff0f38000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7de0000)

which is linked against both libgcj.so.9 and libgcj_bc.so.1.  How does this
happen?


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2008-12-10 11:14 -------
libgcj_bc.so is a dummy shared library, which is meant for ld(1) only and
provides just a subset of libgcj.so symbols that are for -findirect-dispatch
only and aren't changing ABI.
libgcj_bc.so.1 is supposed to be a small library with just DT_NEEDED
libgcj.so.LATEST and DT_SONAME libgcj_bc.so.1, providing no symbols at all.

-findirect-dispatch programs link just against -lgcj_bc, not -lgcj and thus can
be used against any libjava version that provides libgcj_bc.so.1.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-12-10 11:16 -------
Because of

/bin/sh ./libtool --tag=GCJ --mode=link
/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/gcc/gcj
-B/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava/
-B/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/gcc/
-L/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava
-fomit-frame-pointer -g -O2  -o ecjx -findirect-dispatch
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
-Djava.class.path=/usr/lib64/gcc/x86_64-suse-linux/4.3/ecj.jar 
-L/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava/.libs
libgcj.la
libtool: link:
/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/gcc/gcj
-B/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava/
-B/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/gcc/
-fomit-frame-pointer -g -O2 -o .libs/ecjx -findirect-dispatch
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
-Djava.class.path=/usr/lib64/gcc/x86_64-suse-linux/4.3/ecj.jar 
-L/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava/.libs
-L/usr/src/packages/BUILD/gcc-4.3.3-20081022/obj-x86_64-suse-linux/x86_64-suse-linux/libjava
./.libs/libgcj.so -lpthread -lrt -ldl -lz -Wl,-rpath
-Wl,/usr/lib64/gcc/x86_64-suse-linux/4.3
libtool: link: creating ecjx

so it uses -findirect-dispatch and explicitly adds libgcj.so


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2008-12-10 11:23 -------
That is a bug then.
I guess libjava/Makefile.am needs to be fixed.
ecjx_LDADD = -L$(here)/.libs libgcj.la
should be likely:
if ENABLE_SHARED
ecjx_LDADD = -L$(here)/.libs
else
ecjx_LDADD = -L$(here)/.libs libgcj.la
endif
(or, if ecj1 is meant to be libgcj.so.X version dependent, shouldn't be
compiled/linked with -findirect-dispatch).


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2008-12-10 11:29 -------
Well, I see we use -findirect-dispatch unconditionally, so I'm trying

ecjx_DEPENDENCIES = libgcj.la libgcj.spec
ecjx_LDADD = -L$(here)/.libs
if USE_LIBGCJ_BC
ecjx_DEPENDENCIES += libgcj_bc.la
else !USE_LIBGCJ_BC
ecjx_LDADD = libgcj.la
endif

instead.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at gcc dot gnu dot org]

------- Comment #10 from aph at gcc dot gnu dot org  2008-12-10 11:32 -------
Created an attachment (id=16870)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16870&action=view)
Link map


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at gcc dot gnu dot org]

------- Comment #11 from aph at gcc dot gnu dot org  2008-12-10 11:32 -------
This looks like a bug to me.

zorro:tmp $ gcj /home/aph/gcc/trunk/ecj.jar
--main=org.eclipse.jdt.internal.compiler.batch.Main -o ecj -findirect-dispatch

zorro:tmp $ readelf -d ecj

Dynamic section at offset 0xa92728 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgcj_bc.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcj.so.9]

Generating a link map doesn't help: there are no references to libgcj.so


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at gcc dot gnu dot org]

------- Comment #12 from aph at gcc dot gnu dot org  2008-12-10 12:17 -------
Look at the exported symbols in the old version of libgcj_bc.so.

Make sure that these symbols are exported:

_Jv_JNI_PopSystemFrame
_Jv_LookupInterfaceMethod
_Jv_MonitorExit
_Jv_RegisterResource


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenther at suse dot de]

------- Comment #13 from rguenther at suse dot de  2008-12-10 12:33 -------
Subject: Re:  [4.4 Regression] libgcj_bc for 4.3 and 4.4
 are binary incompatible but have the same SONAME

On Wed, 10 Dec 2008, aph at gcc dot gnu dot org wrote:

> ------- Comment #12 from aph at gcc dot gnu dot org  2008-12-10 12:17 -------
> Look at the exported symbols in the old version of libgcj_bc.so.
> 
> Make sure that these symbols are exported:
> 
> _Jv_JNI_PopSystemFrame
> _Jv_LookupInterfaceMethod
> _Jv_MonitorExit
> _Jv_RegisterResource

readelf -s libgcj_bc.so  | grep
'_Jv_RegisterResource\|_Jv_JNI_PopSystemFrame\|_Jv_LookupInterfaceMethod\|_Jv_MonitorExit'
    43: 0000000000001330     2 FUNC    GLOBAL DEFAULT   12
_Jv_LookupInterfaceMethod

so only _Jv_LookupInterfaceMethod is there.  But they are all provided by
both libgcj.so.9 and libgcj.so.10 (which is what /usr/lib64/libgcj_bc.so.1
links to).  The libgcj_bc.so is in /usr/lib64/gcc/x86_64-suse-linux/4.3
and thus only used if you link with gcj 4.3.

Richard.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at redhat dot com]

------- Comment #14 from aph at redhat dot com  2008-12-10 12:46 -------
Subject: Re:  [4.4 Regression] libgcj_bc for 4.3 and 4.4
 are binary incompatible but have the same SONAME

rguenther at suse dot de wrote:

>> Look at the exported symbols in the old version of libgcj_bc.so.
>>
>> Make sure that these symbols are exported:
>>
>> _Jv_JNI_PopSystemFrame
>> _Jv_LookupInterfaceMethod
>> _Jv_MonitorExit
>> _Jv_RegisterResource
> 
> readelf -s libgcj_bc.so  | grep
> '_Jv_RegisterResource\|_Jv_JNI_PopSystemFrame\|_Jv_LookupInterfaceMethod\|_Jv_MonitorExit'
>     43: 0000000000001330     2 FUNC    GLOBAL DEFAULT   12
> _Jv_LookupInterfaceMethod
> 
> so only _Jv_LookupInterfaceMethod is there.

Right, so that's probably what's causing the DT_NEEDED for libgcj.so.9.

> But they are all provided by
> both libgcj.so.9 and libgcj.so.10 (which is what /usr/lib64/libgcj_bc.so.1
> links to).  The libgcj_bc.so is in /usr/lib64/gcc/x86_64-suse-linux/4.3
> and thus only used if you link with gcj 4.3.

Right, so this is a bug in gcj 4.3.  All symbols used by BC-compiled
programs need to be in libgcj_bc.so.

As has already been said, /usr/lib64/libgcj_bc.so.1 is not a link
to libgcj.so.x in FSF gcj.

Andrew.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[rguenther at suse dot de]

------- Comment #15 from rguenther at suse dot de  2008-12-10 13:14 -------
Subject: Re:  [4.4 Regression] libgcj_bc for 4.3 and 4.4
 are binary incompatible but have the same SONAME

On Wed, 10 Dec 2008, aph at redhat dot com wrote:

> ------- Comment #14 from aph at redhat dot com  2008-12-10 12:46 -------
> Subject: Re:  [4.4 Regression] libgcj_bc for 4.3 and 4.4
>  are binary incompatible but have the same SONAME
> 
> rguenther at suse dot de wrote:
> 
> >> Look at the exported symbols in the old version of libgcj_bc.so.
> >>
> >> Make sure that these symbols are exported:
> >>
> >> _Jv_JNI_PopSystemFrame
> >> _Jv_LookupInterfaceMethod
> >> _Jv_MonitorExit
> >> _Jv_RegisterResource
> > 
> > readelf -s libgcj_bc.so  | grep
> > '_Jv_RegisterResource\|_Jv_JNI_PopSystemFrame\|_Jv_LookupInterfaceMethod\|_Jv_MonitorExit'
> >     43: 0000000000001330     2 FUNC    GLOBAL DEFAULT   12
> > _Jv_LookupInterfaceMethod
> > 
> > so only _Jv_LookupInterfaceMethod is there.
> 
> Right, so that's probably what's causing the DT_NEEDED for libgcj.so.9.
> 
> > But they are all provided by
> > both libgcj.so.9 and libgcj.so.10 (which is what /usr/lib64/libgcj_bc.so.1
> > links to).  The libgcj_bc.so is in /usr/lib64/gcc/x86_64-suse-linux/4.3
> > and thus only used if you link with gcj 4.3.
> 
> Right, so this is a bug in gcj 4.3.  All symbols used by BC-compiled
> programs need to be in libgcj_bc.so.
> 
> As has already been said, /usr/lib64/libgcj_bc.so.1 is not a link
> to libgcj.so.x in FSF gcj.

Ok, I'm checking what happens on pristine 4.3 branch and report back.
Maybe it's somehow my own fault (the Debian libgcj_bc seems to have
the proper symbols).

Richard.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at gcc dot gnu dot org]

------- Comment #16 from aph at gcc dot gnu dot org  2008-12-10 13:26 -------
You'll still have the same problem until the change that adds the symbols to
libgcj_bc.so is back-ported to the gcc 4.3 branch.

I should have applied that change to the gcc 4.3 branch, but I didn't
realize that this problem would occur.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2008-12-10 13:30 -------
For #c12, those weren't present in 4.3 libgcj_bc.so, but I don't see why it
matters.  4.3 linked ecj1 doesn't need any of those symbols.  The reason why it
has DT_NEEDED libgcj.so.9 is IMHO that libgcj.la was in ecjx's LDADD, so
libtool
linked it with -lgcj (and as -Wl,--as-needed -lgcj -Wl,--no-as-needed wasn't
used, it was added to DT_NEEDED unconditionally).
The fix really is not to have libgcj.la in LDADD for dynamically linked ecj1.
I'm just not sure about !ENABLE_SHARED build if USE_LIBGCJ_BC is true, maybe
libgcj.la is needed in that case (not sure if libgcj_bc.la has libgcj.la as a
dependency in that case).


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at redhat dot com]

------- Comment #18 from aph at redhat dot com  2008-12-10 13:46 -------
Subject: Re:  [4.4 Regression] libgcj_bc for 4.3 and 4.4
 are binary incompatible but have the same SONAME

jakub at gcc dot gnu dot org wrote:
> ------- Comment #17 from jakub at gcc dot gnu dot org  2008-12-10 13:30 -------
> For #c12, those weren't present in 4.3 libgcj_bc.so, but I don't see why it
> matters.  4.3 linked ecj1 doesn't need any of those symbols.  The reason why it
> has DT_NEEDED libgcj.so.9 is IMHO that libgcj.la was in ecjx's LDADD, so
> libtool
> linked it with -lgcj (and as -Wl,--as-needed -lgcj -Wl,--no-as-needed wasn't
> used, it was added to DT_NEEDED unconditionally).
> The fix really is not to have libgcj.la in LDADD for dynamically linked ecj1.
> I'm just not sure about !ENABLE_SHARED build if USE_LIBGCJ_BC is true, maybe
> libgcj.la is needed in that case (not sure if libgcj_bc.la has libgcj.la as a
> dependency in that case).

We, then, have two unrelated bugs to fix on 4.3 branch.

1.  The missing symbols in libgcj_bc that cause BC-compiled applications
to have a DT_NEEDED libgcj.so.9.

2.  ecjx's LDADD to libgcj.la.

Andrew.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #19 from jakub at gcc dot gnu dot org  2008-12-10 14:08 -------
Yes, and 2) needs to be fixed on the trunk as well.


-- 


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[aph at gcc dot gnu dot org]

------- Comment #20 from aph at gcc dot gnu dot org  2008-12-10 14:29 -------
OK, I will do all these fixes.


-- 

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aph at gcc dot gnu dot org
                   |dot org                     |


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

[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2008-12-19 14:58 -------
Subject: Bug 38396

Author: jakub
Date: Fri Dec 19 14:57:29 2008
New Revision: 142834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142834
Log:
        PR libgcj/38396
        * configure.ac (use_libgcj_bc): Set to no if not enable_shared.
        (LIBGCJ_SPEC): Use -lgcj instead of -lgcj_bc even for -static
        or -static-libgcj.
        * Makefile.am (ecjx_SOURCES): Add ecjx.cc.
        (ecjx_LDADD): Don't add libgcj.la when
        NATIVE && USE_LIBBGCJ_BC.
        * ecjx.cc: New file.
        * Makefile.in: Regenerated.
        * configure: Regenerated.

Added:
    trunk/libjava/ecjx.cc
Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/Makefile.am
    trunk/libjava/Makefile.in
    trunk/libjava/configure
    trunk/libjava/configure.ac


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2008-12-19 15:02 -------
1) doesn't exist on the trunk, 2) fixed there.
Both 1) and 2) need still fixing on 4.3 branch, a backport of
r142834 should cure 2), 1) needs a separate patch.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.2
      Known to work|                            |4.4.0
            Summary|[4.4 Regression] libgcj_bc  |[4.3 Regression] ecj1 linked
                   |for 4.3 and 4.4 are binary  |against both -lgcj and -
                   |incompatible but have the   |lgcj_bc
                   |same SONAME                 |


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|4.4.0                       |4.3.3


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[doko at ubuntu dot com]

------- Comment #23 from doko at ubuntu dot com  2009-01-11 08:30 -------
r143261 is needed for the backport as well.


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[aph at gcc dot gnu dot org]

------- Comment #24 from aph at gcc dot gnu dot org  2009-01-12 17:36 -------
Subject: Bug 38396

Author: aph
Date: Mon Jan 12 17:35:48 2009
New Revision: 143301

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143301
Log:
2009-01-12  Andrew Haley  <aph@redhat.com>

        PR libgcj/38396:
        * libgcj_bc.c: Sort lines.
        *(_Jv_LookupInterfaceMethod, _Jv_MonitorExit,
        _Jv_RegisterResource, _Jv_JNI_PopSystemFrame): Add.

        * sun/misc/natUnsafe.cc (spinlock contructor): Call sched_yield().

Modified:
    branches/gcc-4_3-branch/libjava/ChangeLog
    branches/gcc-4_3-branch/libjava/libgcj_bc.c
    branches/gcc-4_3-branch/libjava/sun/misc/natUnsafe.cc


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2009-01-24 10:21 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.3                       |4.3.4


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[dominiq at lps dot ens dot fr]

------- Comment #26 from dominiq at lps dot ens dot fr  2009-04-04 21:01 -------
Out of curiosity, how can a pr like this one be "UNCONFIRMED"?


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[aph at redhat dot com]

------- Comment #27 from aph at redhat dot com  2009-04-04 21:13 -------
Subject: Re:  [4.3 Regression] ecj1 linked against both
 -lgcj and -lgcj_bc

dominiq at lps dot ens dot fr wrote:

> Out of curiosity, how can a pr like this one be "UNCONFIRMED"?

Insanity is the only explanation I can think of.


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[dominiq at lps dot ens dot fr]

------- Comment #28 from dominiq at lps dot ens dot fr  2009-04-04 21:17 -------
> Insanity is the only explanation I can think of.

It does not seem the only instance;)


-- 


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[rguenth at gcc dot gnu dot org]

------- Comment #29 from rguenth at gcc dot gnu dot org  2009-06-25 12:40 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to fail|4.3.2                       |4.3.2 4.3.3
      Known to work|4.4.0                       |4.3.4 4.4.0
         Resolution|                            |FIXED


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

[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc

[rguenth at gcc dot gnu dot org]

------- Comment #30 from rguenth at gcc dot gnu dot org  2009-06-25 12:40 -------
Subject: Bug 38396

Author: rguenth
Date: Thu Jun 25 12:40:30 2009
New Revision: 148944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148944
Log:
2009-06-25  Richard Guenther  <rguenther@suse.de>

        Backport from mainline
        2008-12-19  Jakub Jelinek  <jakub@redhat.com>

        PR libgcj/38396
        * configure.ac (use_libgcj_bc): Set to no if not enable_shared.
        (LIBGCJ_SPEC): Use -lgcj instead of -lgcj_bc even for -static
        or -static-libgcj.
        * Makefile.am (ecjx_SOURCES): Add ecjx.cc.
        (ecjx_LDADD): Don't add libgcj.la when
        NATIVE && USE_LIBBGCJ_BC.
        * ecjx.cc: New file.
        * Makefile.in: Regenerated.
        * configure: Regenerated.

        2009-01-11  Matthias Klose  <doko@ubuntu.com>

        * Makefile.am (ecjx_LDADD): Add $(extra_ldflags).
        * Makefile.in: Regenerate.

Added:
    branches/gcc-4_3-branch/libjava/ecjx.cc
Modified:
    branches/gcc-4_3-branch/libjava/ChangeLog
    branches/gcc-4_3-branch/libjava/Makefile.am
    branches/gcc-4_3-branch/libjava/Makefile.in
    branches/gcc-4_3-branch/libjava/configure
    branches/gcc-4_3-branch/libjava/configure.ac


-- 


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