Build-Breaking MingW 3.3 Stuff (was Published Sources & Scripts for MingW GCC 3.3 Build)
Fri Apr 11 17:10:00 GMT 2003
Mohan Embar writes:
> >Please check out and download the 3.3 branch and try it on Windows.
> >If there's anything still broken we need to know.
> I can tell you right away which things are broken that I know about.
> Although I believe this list is complete, I will do another get and build
> this weekend.
Thanks. I checked in your strict case patch. Of course I haven't
tested it, so please make sure you do that.
> In general, I list extra unofficial or uncommitted patches on my download
> ...which provide a vague idea of what I think is missing from the sources.
> Here is a more detailed list:
> BUILD-BREAKING PROBLEMS
> 1. Patch: Suppress MingW Build-Busting Net Code
> Remarks: Michael Koch has split off the Win32 and Posix NET
> code at the trunk, but not in 3.3. If his changes are deemed too
> radical for 3.3, the above patch should be a quick an ugly fix
> which suppresses the problems for 3.3. Michael had originally commented
> that for gnu/java/nio/natSelectorImpl.cc, I should really
> define a do-nothing _Jv_select for Win32.. So there are three
> possibilities (listed in descending order of correctness)
> - apply Michael's trunk changes to 3.3
> - define a dummy _Jv_select as per Michael
> - just use my #ifdef in the above patch
Tom, do you care which one of these happens?
> Applying Michael's changes (with a subsequent iteration on the
> Win32 side to fix broken things) would be the most desirable, but
> Michael said he wasn't able to commit to 3.3.
> Doing a dummy _Jv_select would leave natSelectorImpl.cc untouched.
Sounds good. Can you please submit a patch that does this for 3.3?
> 2. Patch: natSocketChannelImpl.cc use elements + explicit cast
> Michael found this to be correct and committed it to the trunk,
> but not 3.3.
Michael, is there a good reason not to apply this to 3.3?
> IRRITATING (but not build-breaking) PROBLEMS
> 3. Patch for Preview: Escape DllMain in boehm-gc (Take 2)
> Not having this prevents creating DLLs on Windows which
> use the gcj runtime. Hans recently said that although the remedy
> wasn't ideal, he was okay with this being checked in:
Tom? What do you think?
> 4. Patch: Make "os.arch" consistent with Sun's JDK on Win32
> On MingW, System.getProperty("os.arch") returns i586 instead
> if x86 which, though seemingly innocuous, causes some things
> (like SWT) to behave incorrectly. Tom didn't put this in because
> he said this stuff belongs more properly in config.host and not here
> (see the followup).
Okay, but let's do something simple like this for 3.3.
> It looks like my case-sensitivity and Erik's 0-concatenation fixes are
> going in, so I can stop hand-adding these and remove them from my
More information about the Java