This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
This is a followup to the thread: http://gcc.gnu.org/ml/java/2005-08/msg00136.html The attached patch (mingw-shared-fix.diff) updates Makefile.am, configure.ac and libltdl/libltdl.h so that a full libgcj.dll can be built for MinGW (this will probably work for Cygwin as well). The patch applies against CVS HEAD as of 9/2/2005. In order to get the build to work, there are a few tweaks that need to be made: - The patch for Bug 21766 must be applied (this is apparently incomplete but allows the build to proceed and work) - The call to mkdir in gcc/libgcov.c must be fixed (no patch available yet) - Decompile routines must be removed from gjavah (see attached gjavah.diff) Note that in the middle of the build, I had to contend with an i686-pc-mingw32-fastjar that wasn't where it was supposed to be. This may have been an environmental problem on my side and I haven't looked into it. Here are a few things to note: - There is an unrelated change in Makefile.am relating to the version information. My toolchain was choking on the grep pattern "^\#". It looked like Make was chopping the rest of the line after the #. I took off the -v and changed the pattern to "^[0-9]" to get past this. - I have only run a couple of limited tests against the build. The test suite was not run. - java.net on MinGW may not be working. I haven't looked into this but did get an error trying to run something that uses it. - At this point the use of enable-runtime-pseudo-relocs and auto-import are required. The DLL build should be considered a toy until this can be worked around. - By ommiting the -no-undefined flag from libgij, a warning is generated at link time and a DLL is not built. This is probably the behavior that makes sense on MinGW, since having a static libgij that pulls in a dynamic libgcj.dll makes more sense in this environment. A more obvious way of suppressing the DLL version of libgij would probably be a good thing. - Exception handling probably does not work across dll boundaries. Now that the build is working, it should be easier to address this. - I used a new and modified version of libtool to make this work. The libtool.m4 and ltmain.sh that I used are attached. Getting the ancient libtool in the distro to work is probably possible. I think I got it almost all the way there with a two-liner change regarding how the AC_LIBTOOL_WIN32_DLL macro is evaluated. I will follow up when I have that working. Comments are welcome. My goal is to get the build machinery in a state where a standard shared build of GCJ is possible out of the box on MinGW. Having this in place will make it easier to address the lurking issues in relation to how DLL's are handled on Win32. TJ
Attachment:
mingw-shared-fix.diff
Description: Binary data
Attachment:
gjavah.c.diff
Description: Binary data
Attachment:
libtool.m4
Description: Binary data
Attachment:
ltmain.sh
Description: Bourne shell script
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |