Inexplicable Parameter-Passing Phenomena w/MinGW GCJ

Thu Sep 11 15:33:00 GMT 2003

Hi All,
>This might or might not be related, but this code yells "Miranda
>Method!" to me. setOption() is defined in the interface SocketOptions,
>which is implemented (but not defined) in the abstract class
>DatagramSocketImpl and finally implemented in the class 
>natPlainDatagramSocketImplXXX.
>>I really simple thing to check would be to explicitly defined
>setOption() as an abstract method in the class DatagramSocketImpl.

Bingo! This worked! I added the abstract methods to both DatagramSocketImpl
and SocketImpl and my MinGW test ran okay again.
Tom's post mentions a key point:
http://gcc.gnu.org/ml/java/2003-02/msg00560.html
In particular, this:
>This may be one of those bugs that only shows up if you compile a lot
>of java files with one gcj command....

We <i>are</i> compiling all .java files with one command now. The weird
thing is that the problem doesn't show up on Linux.
Bryce: I'm not completely clear on how I would use -findirect-dispatch.
Are you suggesting adding it to the libgcj piece or the build script for
my test executable? When I try it with my test executable, I get tons
of multiply defined symbols because I'm using a static libgcj.
Given that Mark pointed out here:
http://gcc.gnu.org/ml/java/2003-03/msg00004.html
...that these are still needed, are we okay with readding these methods to
DatagramSocketImpl and SocketImpl? If so, Michael: do you want me to submit
a patch for this or are you okay with doing this yourself?
Together with Anthony's patch:
http://gcc.gnu.org/ml/java-patches/2003-q3/msg00591.html
...this would make MinGW okay again (at least the cross compiler).
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/