Bug 42143 - [4.6/4.7/4.8 Regression] gcj creates "dummy" variables
Summary: [4.6/4.7/4.8 Regression] gcj creates "dummy" variables
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.3.4
: P5 normal
Target Milestone: 4.6.4
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2009-11-22 12:51 UTC by Kurt Roeckx
Modified: 2014-04-03 18:09 UTC (History)
10 users (show)

See Also:
Known to work: 4.3.3
Known to fail: 4.3.4, 4.4.2
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Roeckx 2009-11-22 12:51:10 UTC

When running the libtool regression tests, I get the following error:
gcj -shared  -Wl,--whole-archive ./.libs/liba1.a ./.libs/liba2.a -Wl,--no-whole-archive     -Wl,-soname -Wl,liba12.so.0 -o .libs/liba12.so.0.0.0
./.libs/liba2.a(A2.o):(.rodata+0x0): multiple definition of `java resource .dummy'
./.libs/liba1.a(A1.o):(.rodata+0x0): first defined here collect2: ld returned 1 exit status

Looking at liba1.a I see:
Relocation section '.rela.text' at offset 0x1ad0 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend000000000005  002600000004 R_X86_64_PLT32    0000000000000000 _ZN4java4lang6ObjectC1 - 4
000000000023  002300000002 R_X86_64_PC32     0000000000000000 _ZGr8_$_dummy - 4

Symbol table '.symtab' contains 54 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    35: 0000000000000000    16 OBJECT  GLOBAL HIDDEN   11 _ZGr8_$_dummy

There is nothing called "dummy" in the source file.  The source
file is:
public class foo1 {
  public static void main(String[] argv) {
    A1 a1 = new A1();

It can also be reproduced with a file that just
has "public class foo1 {}"

I get this error with Debian's 4.3.4-4. The version 4.3.2-2 does not generate that symbol.  An old build log of libtool with gcj version 4.3.3-3 also does not show the error.
Comment 1 Kurt Roeckx 2009-12-06 16:03:56 UTC
Can someone please take a look at this?
Comment 2 Richard Biener 2010-02-16 10:34:40 UTC
It works for me with FSF 4.3.4.  You might want to report this to Debian.
Comment 3 Philip James 2010-03-09 21:43:30 UTC
I was able to reproduce in Fedora Core 6 and Fedora Core 11

mipsel-linux-gcc (GCC) 4.3.4 20090326 (prerelease)

I was able to avoid the problem by first compiling my .java files to .class files, then compiling the .class files to .o files. (compiling straight from .java to .o introduced the dummy symbol)
Comment 4 Michele Bini 2010-03-10 08:05:36 UTC
Yesterday I filed the suspiciously similar bug 42143 with a really simple test case that fails on gcc 4.4.3 and used to work with gcc 4.2.2. As I wrote in the description for that bug I suspect it's actually a duplicate of this bug but I can't confirm it easily as I don't have binutils sources at hand.
Comment 5 Michele Bini 2010-03-10 08:09:03 UTC
(In reply to comment #4)
> [...] suspiciously similar bug 42143 [...]

I meant bug 43302...
Comment 6 Kurt Roeckx 2010-04-23 19:49:10 UTC
So can someone please comment on this?
Comment 7 Greg Larkin 2010-05-03 18:36:01 UTC
(In reply to comment #6)
> So can someone please comment on this?

I recently encountered this problem while using gcc/gcj 4.5 with ecj-4.5.jar to compile the pdftk utility (http://www.accesspdf.com/pdftk/) on FreeBSD.  I maintain the pdftk port for FreeBSD, and I previously used gcc/gcj 4.2 with ecj-4.3.jar without any problems.

I found a workaround by patching the pdftk Makefiles like so:

 # implicit rules for creating A from B

 %.o : %.java
        $(GCJ) $(GCJFLAGS) -c $< -o $@
+       ${OBJCOPY} -L '_ZGr8_$$_dummy' $@

The FreeBSD objcopy command changes the .dummy resource from global scope to local scope in each .o file.  After doing that, the pdftk link phase succeeded instead of dying with a ton of "duplicate symbol" errors.

After searching for the source of the duplicate symbol, I think I found it here:


If the patch included in this message is the source of the duplicate symbol problem, then I wonder if it could be fixed like so?

String someRandomString = <generate random string>();
ZipEntry entry = new ZipEntry(".dummy" + someRandomString);

Feedback welcome,
Greg Larkin
Comment 8 Richard Biener 2010-05-22 18:13:47 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 9 Richard Biener 2011-06-27 12:13:26 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 10 Jakub Jelinek 2012-03-13 12:46:19 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 11 Roumen Petrov 2012-04-08 12:19:47 UTC
Why is still "unconfirmed" ?
Comment 12 Steven Bosscher 2012-11-09 23:21:27 UTC
If it comes from ecj, it's not a gcc bug.
(see bug 43302)
Comment 13 mathar@mpia-hd.mpg.de 2014-04-03 18:09:08 UTC
This bug should be reopened because the source code GCCMain.java is only in the gcj version of org/eclipse/jdt/internal/compiler/batch/GCCMain.java . It does *not* exist in the associated current ecj-4.3.2 repository of the eclipse project, which does not have any GCCMain.java at all. Certainly the problem is in the gcj, not in the eclipse project. They cannot fix a bug that is not theirs.
See also  http://download.eclipse.org/eclipse/downloads/ and http://stackoverflow.com/questions/2567230/gcj-creates-duplicate-dummy-symbol .
The problem still exists in ecj-4.9.jar .