Re: Another GCJ win32 bug "regex" (String.split()) not working

[Bryce McKinlay <mckinlay at redhat dot com>]

Andreas Grunewald wrote:

> > This error is due to the limitations of static linking. libgcj's 
> > regexp code requires the gnu/regexp/MessageBundle resource. Usually 
> > this is compiled in to libgcj.so, but when static linking there is no 
> > way for the compiler to know about this dynamically loaded resource.
>
> I don't understand this, what do you mean with "usually this is 
> compiled in to libgcj.so" if it is compiled into it then why isn't it 
> there ?


Because the linker doesn't include all of libgcj in your generated 
binary, only the bits that it thinks are needed.

> And why is there no way for the compiler ? If String.slipt() is 
> compiled correctly it should work, or throw an error at compiletime, 
> that a needed resource is unavailable. I don't understand why this can 
> not be resolved at compile time.


Because the resource is not actually referenced in Java code. It is 
loaded dynamically via a ResourceBundle.getBundle() call. The compiler 
can only resolve "hard" linkage. Likewise, classes loaded dynamically 
via Class.forName() and other dynamic mechanisms have the same problem.

There are possible solutions for this and ideas for ways to improve the 
situation - this has all been discussed on this list many times in the 
past. But so far, nothing has been implemented to improve static 
linking. In general, we only recommend/support dynamic linking for Java 
applications.

> You'll need to either explicitly tell GCJ to link this file into your 
> .exe,
>
> Could you give me a hint how I could do this ?


--resource. See: 
http://gcc.gnu.org/onlinedocs/gcj/Code-Generation.html#Code-Generation

> > My guess is that your libgcj probably does have debugging 
> > information, but libgcj can not yet use it when printing stack traces.
>
>
> Why is that ?


Largely because GCC is not using DWARF EH info on Windows, and the stack 
trace code in libgcj relies on this to determine which class/method 
belongs to each stack frame.

> Thanks for the fast answer, I really whish I could help are there any 
> efforts of a more intensive Win32 development. Especially in making 
> the gcj easier to use and easier to install.


Yes, there is not a great deal of activity on GCJ for Win32 right now. 
We would certainly welcome anyone who wants to step up and improve things.

Bryce