Static build failing to load classes

Thu Nov 17 00:41:00 GMT 2005

Scott Gilbertson wrote:
>>Welcome to the world of static linking.
>>> Been there for years, happily for the most part. I'm just hoping to be able
> to use something newer than the hacked (to make xlib peers work) branch-4.0
> snapshot I presently use with my statically-linked application. Also to
> maybe someday use a released gcc.
>
I can only tell you what works for me on 3.4.3.
use nm to see if the offending class is being included in the final 
static object if not, you need to use one of the techniques I suggested 
to force it to link (you might use the -u option to ld also but I have 
never tried it for this purpose).
If the class is being included, then there is some other problem. It 
looks like you have gdb, so you should be all set to figure out what it is.
David Daney.
>>>I think an alternatative would be to do this somewhere:
>>>>void dummy()
>>{
>>Object o = new gnu.java.locale.LocaleInformation();
>>}
>>>>> gnu/java/lang/MainThread.java already contains:
> static final Class Klocale = gnu.java.locale.LocaleInformation.class;
> In fact, that's the line (line #61) where the problem happens, as shown in
> the backtrace.
>> Besides that, the following command doesn't solve it:
> gcj -static --main=Hello -Wl,--whole-archive -Wl,-lgcj -Wl,--no-whole-archiv
> e -g -o Hello.bin Hello.java
>> It makes a gargantuan binary (32 megs, up from 17 megs), but still aborts.
> So I don't think it's a matter of not having a certain class included in the
> binary.
>> ----- Original Message ----- 
> From: "David Daney"
> Sent: Wednesday, November 16, 2005 6:07 PM
> Subject: Re: Static build failing to load classes
>>>>>Scott Gilbertson wrote:
>>>>>I'm trying to do a static build with today's gcj code. With a trivial
>> java
>>>>program,
>>>it crashes, apparently unable to load a class I'm reasonably sure is
>>>included
>>>in the binary. Is this a known problem?
>>>>>>>>>Welcome to the world of static linking.
>>>>In the startup code (generated by the magic --main=) we add this:
>>>>extern int _ZN3gnu4java6locale8Calendar6class$E;
>>int *dummy1 = &_ZN3gnu4java6locale8Calendar6class$E;
>>>>extern int _ZN3gnu4java6locale17LocaleInformation6class$E;
>>int *dummy2 = &_ZN3gnu4java6locale17LocaleInformation6class$E;
>>>>extern int _ZN3gnu3gcj7convert12Output_ASCII6class$E;
>>int *dummy3 = &_ZN3gnu3gcj7convert12Output_ASCII6class$E;
>>>>extern int _ZN3gnu3gcj7convert28Output_UnicodeLittleUnmarked6class$E;
>>int *dummy4 = &_ZN3gnu3gcj7convert28Output_UnicodeLittleUnmarked6class$E;
>>>>extern int _ZN3gnu3gcj7convert11Output_UTF86class$E;
>>int *dummy5 = &_ZN3gnu3gcj7convert11Output_UTF86class$E;
>>>>>>You can get the startup code by using -save-temps and then modify the
>>startup code file and compile it with gcc and re-link without
>> the --main=...
>>>>>>>I think an alternatative would be to do this somewhere:
>>>>void dummy()
>>{
>>Object o = new gnu.java.locale.LocaleInformation();
>>}
>>>>Which would force the missing class to be loaded. You will probably
>>have to iterate to get them all.
>>>>As Pinski said in the other reply, you could use --whole-archive, but
>>that makes the resulting executable much larger. If you use
>>--whole-archive you might as well just use the shared libgcj object.
>>>>David Daney.
>>