Re: GCJ Build Problem (CVS)

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Brad Cox wrote:

> PROGRESS!! gcj built! Thanks for the help!! cvs update -d did the 
> trick. Only problem was the time it took to drag in ada stuff I'll 
> never use.

Remember to use "-z9" when you do a cvs update, to turn on compression.

> But I'm still hitting snags. The first is I haven't yet figured out 
> the switches to make jikes style all at once compiles (gcj *.java) 
> generate an archive.


Archive as in a ".a"? I don't think GCJ can do that automatically. It 
can generate a shared library (.so) or just a plain object file (.o). 
Why would you need to use a .a rather than a .o?

>
> This leads to the following confusing messages. Consider relinking 
> WHAT? My application? GCJ? (hope not, that's PAINFUL). Some shared 
> library? Which one?
>
> a.out: Symbol `_ZN4java4lang12StringBuffer6class$E' has different size 
> in shared object, consider re-linking 


This means that the size of the java.lang.Class object that your 
newly-created binary is expecting is not consistent with the size of 
java.lang.Class in the libgcj.so seen by the linker. This can happen 
because we added new fields to it at some point, changing the ABI 
between the compiler and the runtime.

So, the problem is that you have an old version of libgcj.so sitting 
around somewhere and the linker is seeing that before the new libgcj.so. 
But normally that should never happen since GCJ finds libgcj.so relative 
to the path of the compiler. You did remember to "make install", right?

> Here's the integrated gcj src/build/deploy directory structure I'm 
> using, which I propose to document in the proposed quick start README 
> mentioned below: 

Usually, I think, people keep the install prefix separate from the 
src/build directory. Maybe this could be causing problems...

regards

Bryce.