| Summary: | [4.6/4.7/4.8 Regression] gcj creates "dummy" variables | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Kurt Roeckx <kurt> |
| Component: | java | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | bugtrack, cagney, gcc-bugs, glarkin, java-prs, mathar, mikbini, pkeller, rwild, steven |
| Priority: | P5 | ||
| Version: | 4.3.4 | ||
| Target Milestone: | 4.6.4 | ||
| Host: | Target: | ||
| Build: | Known to work: | 4.3.3 | |
| Known to fail: | 4.3.4, 4.4.2 | Last reconfirmed: | |
Can someone please take a look at this? It works for me with FSF 4.3.4. You might want to report this to Debian. 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) 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. (In reply to comment #4) > [...] suspiciously similar bug 42143 [...] I meant bug 43302... So can someone please comment on this? (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: http://gcc.gnu.org/ml/java-patches/2009-q1/msg00049.html 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 GCC 4.3.5 is being released, adjusting target milestone. 4.3 branch is being closed, moving to 4.4.7 target. 4.4 branch is being closed, moving to 4.5.4 target. Why is still "unconfirmed" ? If it comes from ecj, it's not a gcc bug. (see bug 43302) 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 . |
Hi, 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.