Re: [Mingw-users] Help wanted: GCJ Java support on mingw32

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

> From: min...@li... 
> [mailto:min...@li...] On Behalf 
> Of Charles Wilson
> Sent: Wednesday, 13 June 2007 6:27 p.m.
> 
> Danny Smith wrote:
>  > Does anyone on this list care enough, have time enough to 
> help support
>  > the GNU Java compiler on mingw32?
>  > It is a big ask.
> 
>  > Get the GCC trunk source code and try to build gcj/libjava on your
>  > machine.
>  > Then ask the next qustion.
> 
> This isn't /directly/ on point, as I'm building on cygwin (wait, keep
> reading...) but it IS win32, and mingw/cygwin share a lot of
> configuration and specialization code in gcc.  Plus, both 
> share numerous
> DLL issues, especially with regards to the runtime libraries.
> 
> So anyway, I was attempted to test Danny's most recent 
> DWARF-2 patch for
> cygming.

Thanks.  Thanks, very much. Really.

> 
> 5. extra dwarf2 patch for cygwin.h
>       It's in changelog of #4, but for some reason it is missing from
> the patch posted at the link above...my version is:
> 
Likewise.
> 
> However, the build failed in libjava, due to stack overflow 
> in jc1.exe.
>   After manually relinking cc1.exe and jc1.exe with 100MB of stack
> (-Wl,--stack,102400000) as recommended here:
>     http://gcc.gnu.org/ml/gcc/2007-06/msg00151.html

Yikes, that is a big stack reserve, but it's a single threaded app.
Hmm, I wonder if --Wl,--stack,big_num
should depend on -mthreads/-pthreads in builtin specs
> 
> and then restarting the make:
> 
> $ make all-target 2>err2.log 1>out2.log
> 
> I got much farther.  However, building jv-convert.exe failed:
> 
> libtool: link: /usr/local/src/gcc/_build/gcc/gcj
> -B/usr/local/src/gcc/_build/i686-pc-cygwin/libjava/
> -B/usr/local/src/gcc/_build/gcc/ -ffloat-store -fomit-frame-pointer
> -g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert
> -shared-libgcc  <<<<<<<<<<<--------- NOTE THIS
> -L/usr/local/src/gcc/_build/i686-pc-cygwin/libjava/.libs
> -L/usr/local/src/gcc/_build/i686-pc-cygwin
> /libjava ./.libs/libgcj.a -ldl -lz -L/opt/lib/gcc/i686-pc-cygwin/4.3.0
> 
> So, even though I am explicitly disabling shared libraries, libjava
> insists on putting -shared-libgcc in the link line.  However, it seems
> that this really doesn't matter; if gcj can't find the shared version,
> it'll link the static one.
> 
> [I've read that there may be issues with static libgcj, tho.  So I may
> be setting myself up for failure here, if the FIRST thing 
> that needs to
> happen is to build libgcj as a DLL -- which requires building 
> libgcc as
> a DLL.  And there's NO support in libgcc/ for doing that on 
> cygwin|mingw]

static libgcj is possible but it is a huge PITA and you get megabyte++
hello_world.exe's 

> __Unwind_Resume', but
> my newly built libgcc.a HAS that symbol...
> 
> $ nm -B libgcc.a | grep Unwind_Resume
> 00001a10 T __Unwind_Resume
> 00001cd0 T __Unwind_Resume_or_Rethrow
> 
> 
> As it happens, the REAL problem was that I was picking up the OLD
> (non-DWARF2) libgcc from 
> ${PREFIX}/lib/gcc/i686-pc-cygwin/4.3.0/, because
>     -L<BUILDDIR>/i686-pc-cygwin/libgcc
> does not show up in the link command above.

Good catch.
> 
> 
> Manually linking jv-convert.exe, but adding that -L option, 
> ALSO fails,
> with the following missing symbol errors (but at least it's not
> complaining about __Unwind_Resume anymore):
> 
> 
> ./.libs/libgcj.a(lt104-misc.o): In function `GC_init_inner':
> /usr/local/src/gcc/_build/i686-pc-cygwin/boehm-gc/../../../gcc
> /boehm-gc/misc.c:680:
> undefined reference to `_GC_get_thread_stack_base'
> 
> and several like:
> 
> /usr/local/src/gcc/_build/i686-pc-cygwin/libjava/../../../../.
> ./gcc/libjava/classpath/javax/swing/text/html/HTMLEditorKit.java:1185:
> undefined reference to `javax::swing::text::html::parser::DTD*
> gnu::javax::swing::text::html::parser::HTML_401F::getInstance()'
> 
> The second issue is a red herring; it turns out that to 
> create a proper 
> HTML_401F.o takes upwards of 1GB; I ran out of virtual memory, so I 
> ended up with a HTML_401F.o that had no symbols.  After rebooting and 
> keeping all extraneous processes to a minumum, I was able to get this 
> file to compile.  Folks with more RAM, or with Windows configure for 
> more VM, won't see this problem.
> 

This sort of thing is what puts me off Java.   Wait till you try to
build the dll.  On mingw its even worse because of case-insensitivity.

> 
> The first issue though, is a real problem: all I found in the 
> archives 
> was this:
> http://gcc.gnu.org/ml/gcc/2007-03/msg00790.html
> 
> Brian Dessent wrote:
>  > Yes, this is unfortunately par for the course with gcc and win32,
>  > which hasn't been able to even bootstrap all languages for many
>  > months.  Ada's broken too, has been since October.  Sad state.  You
>  > can get gcj limping again with something like this:
>  >
>  > --- win32_threads.c     (revision 121494)
>  > +++ win32_threads.c     (working copy)
>  > @@ -337,6 +337,11 @@
>  >      }
>  >  # endif
>  >
>  > +GC_PTR GC_get_thread_stack_base()
>  > +{
>  > +  return 0;
>  > +}
>  > +
>  >  void GC_push_all_stacks()
>  > {
>  >    DWORD thread_id = GetCurrentThreadId();
> 
> Snooping in the 4.2 branch ViewVC, it looks like this never 
> got fixed in
> the 4.2 branch, either.  Frankly, though, on cygwin I'm surprised that
> boehm-gc doesn't just use regular posix thread support.  In any case,
> mingw will need something like the above.

Not. Use is protected by  # ifdef GC_PTHREADS, which is defined by
cygwin but not by mingw.  So WTF is boehm-gc doing in win32_threads.c on
cygwin?

> 
> So, I kicked off the make again -- but this time, to avoid the issues 
> with picking the old non-dwarf2 libgcc.a in ${PREFIX}, I 
> added -L on the 
> command line:
> 
> $ make all-target -L<BUILDDIR>/i686-pc-cygwin/libgcc 
> 2>err3.log 1>out3.log
> 
> This fixed up libgcjgc.a, and updated libgcj.a with the new 
> HTML_401F.o 
> -- and all of the java tools built.  And I was off to 
> libgomp, and make 
> install.

I haven't played with libgomp and thread-local-storage for awhile on
cygwin. With win32-pthread layer, libgomp seems to work OK on mingw32.
> 
> However, it's now after 2am local, so more info will have to 
> wait until 
> tomorrow --err, later today.  Since I believe these notes 
> will be useful 
> to cygwinners, I'll be posting a near-duplicate of this 
> message to the 
> cygwin list as well (not cross-posted, because then subscription-only 
> posting to mingw will bifurcate the threads, anyway)
> 

Thanks again.
Danny
> -- 
> Chuck
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> 

Re: [Mingw-users] Help wanted: GCJ Java support on mingw32

A native Windows port of the GNU Compiler Collection (GCC)

Re: [Mingw-users] Help wanted: GCJ Java support on mingw32