Dummy resources in object files?

Michele Bini <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
Hello everybody and please excuse me if this is not the proper place to
ask but I didn't find another one.

After upgrading from gcc 4.2.2 to 4.4.3 I started to get link-time
complaints about "multiple definition of `java resource .dummy'".

My executable is made in two steps. First groups of java sources are
compiled to .o files (the sources come from various java libraries and I
have one .o file per library) and then these .o files are linked into an
executable like this:

gcj -o myprg --main=MyProg bins.o lib1.o lib2.o ...

Here I get the "multiple definition" error and indeed most of the .o
files I produce with gcj 4.4.3 define the symbol _ZGr8_$_dummy which,
looking gcj sources, should be a resource called ".dummy".

As I have no .dummy resource (actually, I have no resources at all) I
started digging. A minimal example to get a .o file containing .dummy is
a foo.java containing just:

public class foo {}

If I build this with:

gcj -c -o foo.o foo.java

foo.o defines _ZGr8_$_dummy. I added a -save-temps and the produced
foo.jar contains an empty .dummy file, too. I also get a foo.zip
containing *only* an empty .dummy entry.

This happens on a centos 5.3 with a self-compiled gcc 4.4.3 configured with:

../gcc-4.4.3/configure --prefix="/opt/focuseek-build-fsk" \
	    --program-suffix=-fsk \
	    --enable-languages=c,c++,java \
	    --enable-shared --enable-threads \
	    --enable-__cxa_atexit \
	    --enable-libgcj-multifile

The configuration is what I used for years with 4.2.2. The md5 for
ecj.jar is d7cd6a27c8801e66cbaa964a039ecfdb and it was retrieved today
with contrib/download_ecj.

Looking in bugzilla I found bug #42143 which looks quite similar but I
don't really know whether this is the same problem, another one or if
I'm doing something wrong.

Thus, any help would be appreciated :)

Thanks,
Michele
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.