From: Charles W. <cwi...@us...> - 2007-06-13 06:25:16
|
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. First, I had to massage the tree in the following ways: 1. patched /usr/include/stdio.h [CYGWIN SPECIFIC] See: http://www.cygwin.com/ml/newlib/2007/msg00296.html 2. patched classpath/native/fdlibm/mprec.h (_EXFUN issue) [CYGWIN SPECIFIC] See: http://gcc.gnu.org/ml/gcc/2007-04/msg00648.html 3. patched basic_string.[h|tcc] per pr24196 See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 This is because I'm configuring with --disable-shared 4. danny's latest dwarf2 patch See: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02051.html 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: Index: gcc/config/i386/cygwin.h =================================================================== --- gcc/config/i386/cygwin.h (revision 125636) +++ gcc/config/i386/cygwin.h (working copy) @@ -38,11 +38,12 @@ %{shared|mdll: %{mno-cygwin:dllcrt2%O%s}}\ %{!shared: %{!mdll: %{!mno-cygwin:crt0%O%s} %{mno-cygwin:crt2%O%s}\ %{pg:gcrt0%O%s}}}\ -" + crtbegin.o%s" #undef ENDFILE_SPEC #define ENDFILE_SPEC \ - "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}" + "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ + crtend.o%s" /* Normally, -lgcc is not needed since everything in it is in the DLL, but we want to allow things to be added to it when installing new versions of @@ -242,3 +243,9 @@ and the -pthread flag is not recognized. */ #undef GOMP_SELF_SPECS #define GOMP_SELF_SPECS "" + + +/* This works on cygwin. */ +#undef TARGET_USE_JCR_SECTION +#define TARGET_USE_JCR_SECTION 1 + That last bit, concerning TARGET_USE_JCR_SECTION, is a bit hopeful. I can't see any reason why cygwin wouldn't support it in the same circumstances where mingw would: both binutils support .jcr, both (now, with Danny's dwarf-2 patch) have crtbegin/crtend obects, etc. I configured as: $ ../gcc/configure \ --prefix=${PREFIX} \ --exec-prefix=${PREFIX} \ --sysconfdir=${PREFIX}/etc \ --libdir=${PREFIX}/lib \ --libexecdir=${PREFIX}/lib \ --with-datarootdir=${PREFIX}/share \ --enable-languages=c,c++,objc,fortran,java \ --with-gcc \ --enable-nls \ --without-included-gettext \ --enable-version-specific-runtime-libs \ --without-x \ --enable-libgcj \ --disable-java-awt \ --with-system-zlib \ --enable-interpreter \ --disable-libgcj-debug \ --enable-threads=posix \ --enable-java-gc=boehm \ --disable-win32-registry \ --disable-sjlj-exceptions \ --enable-hash-synchronization \ --enable-libstdcxx-debug \ --enable-cxx-flags='-fno-function-sections -fno-data-sections' \ --disable-symvers \ --enable-libgomp \ --with-arch=i486 \ --with-tune=i686 \ --disable-werror \ --disable-shared $ make bootstrap 2>err.log 1>out.log 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 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] Now, the errors I got were lots of 'missing symbol __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. 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. 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. 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. 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) -- Chuck |