GCJ 3.4 + MingW = Trouble

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi People,

Has anyone attempted to build GCC/GCJ 3.4 under MingW? I have been
doing battle with this for several days but to no avail. Here are
a list of things I'm coming across:

MINOR ISSUES

Here are some minor issues which probably have relatively straightforward
workarounds. I have not whole-heartedly researched the lists for discussion
of these because I am not really concerned about resolving these right away. If
you want to point me in the right direction with these, feel free to do
so, but I'll do more digging later:

Cross build:
- libstdc++-v3: bits/stl-threads.h
  no _Atomic_swap defined if __GTHREAD_MUTEX_INIT not defined

  looks like Danny Smith is on top of this one:

  http://gcc.gnu.org/ml/libstdc++/2003-05/msg00065.html

- libstdc++-v3: config/io/basic_file_stdio.h
  FIONREAD defined but no ioctl() under MingW

  looks like Danny is on top of this too:

  http://gcc.gnu.org/ml/libstdc++/2003-03/msg00301.html

On ths plus side, when I hacked around these problems, I got a
cross compiler that could do STL! This wasn't the case with the
3.3 build.

Crossed-Native Build (cross compiler builds MingW native compiler):
- libstdc++-v3: configure.in

  if build!=host and host=target, CXX somehow gets blanked out
  at configure time.

I haven't attempted to resolve this and build past this point.

MAJOR ISSUES

I am only attempting the cross build now. When I build the cross
compiler and use it to generate a Win32 executable for a simple
HelloWorld program, the generated program crashes with a segmentation
violation. At first blush, this doesn't appear to be the same issue
as this:

http://gcc.gnu.org/ml/gcc/2003-04/msg00968.html

...because the crossed-native jar.exe as well as simple cross-compiled
STL executables I've tried all seem to work fine.

I don't know what flags to use to build a gdb-debuggable compiler (naive
attempts to replace -g0 -O2 with -g2 -O0 and remove the -s flag in Ranjit's
build scripts gave me libgcj link-time errors with multiply defined symbols),
so I've resorted to peppering the code with printfs.

The executable dies in this line:

INIT_SEGV

of libjava/prims.cc. More specifically, it dies in this line of the macro
expansion of include/default-signal.h:

nullp = new java::lang::NullPointerException ();

If I comment out the call to INIT_SEGV in prims.cc, the program will die
a few lines further in prims.cc:

no_memory = new java::lang::OutOfMemoryError;

In both cases, the runtime is choking at a location I haven't been able to
pinpoint yet. It does look like we are traipsing around in the garbage collector
and successfully allocating memory blocks and that the GC is calling
backtrace() a couple of times in win32.cc, but I haven't found anything
suspect yet. I know we don't make it to NullPointerException.NullPointerException(),
but we do make it to Throwable.fillInStackTrace() (but I haven't ascertained
that the Throwable in question is the NullPointerException instance we're trying
to create).

I tried swapping out the new libjava for the old 3.3 one, but the new
compiler finds stuff illegal now that it didn't before, so this is
definitely barking up the wrong tree.

Any ideas on how I should proceed? Forge ahead with printfs? Any AHAs as to weird
vtable / object layout / whatever issues new to 3.4 that haven't been validated
under MingW? Is there a better approach?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/