333777 - w32api-3.7 is required to build moz apps with mingw gcc

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[cls]

Due to the Thebes landing (bug 328499) and other bugs (bug 162361), we now require the cvs version of w32api to build gecko on win32 using gcc.  We need to bump the minimum required version of w32api so that people with older versions will know that they need to upgrade.  Unfortunately, the cvs version of w32api.h still has the previous release number so we'll have to wait until their next release.

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=162361#c156
https://bugzilla.mozilla.org/show_bug.cgi?id=328499#c48

Comment 1

[cls]

Attachment: Require newly released w32api 3.7

Comment 2

[Masatoshi Kimura [:emk]]

Changing summary to reflect new reality.

Comment 3

[cls]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1653; previous revision: 1.1652
done

Comment 4

[Benjamin Smedberg]

Chris, the new w32api isn't actually required for the branches, is it?

Comment 5

[cls]

The changes from bug 162361 require w32api >= 3.7 .

Btw, I'm also hitting a problem where I need to define _WIN32_WINNT & WINVER to 0x500 to workaround the problem that mingw only defines WM_IME_REQUEST if _WIN32_WINNT >= 0x0500 but defines tagRECONVERTSTRING unconditionally.  (I can't find the associated bug.)  

http://lxr.mozilla.org/mozilla1.8.0/source/widget/src/windows/nsWindow.cpp#590

Comment 6

[Benjamin Smedberg]

Comment on attachment 218533 [details] [diff] [review]
Require newly released w32api 3.7

ok, but that patch is not headed for 1.8.0.

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 218533 [details] [diff] [review]
Require newly released w32api 3.7

denying approval1.8.0.4: too late for this release. I doubt we want to change this in any 1.8.0.x release.

Comment 8

[Masatoshi Kimura [:emk]]

(In reply to comment #5)
> Btw, I'm also hitting a problem where I need to define _WIN32_WINNT & WINVER to
> 0x500 to workaround the problem that mingw only defines WM_IME_REQUEST if
> _WIN32_WINNT >= 0x0500 but defines tagRECONVERTSTRING unconditionally.  (I
> can't find the associated bug.)  

I changed it as a part of bug 330276.
We couldn't land the whole 330276, but you could land only relevant part.

Comment 9

[[e-mail]]

(In reply to comment #5)
>The changes from bug 162361 require w32api >= 3.7
They do? I've been happily building the branch with 2.4 until you bumped the version :-( I'm backrevving my tinderbox to see if it still breaks.
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-SeaMonkey

Comment 10

[cls]

*sigh* I just downgraded my setup to w32api 2.4 along with the current mingw-runtime 3.9, gcc 3.4.5 & binutils 2.16.91 and I get the same error as bug 328499 comment 49 which was resolved by modifying winver.h (or upgrading to w32api 3.7).  See bug 162361 comment 166.

I see that the tinderbox is using gcc 3.2.3.  Perhaps the older version of gcc was more lenient about the casts?

Comment 11

[[e-mail]]

You're right, earlier versions of gcc only warn about the const cast.

Comment 12

[cls]

Ok.  I'm fine with backing this out of the 1.8 branch if older versions of gcc work and we support using them.  I don't think the issue is big enough to warrant an extended configure test (w32api 2.x + gcc 3.2 vs w32api 3.x + gcc 3.4?).
I didn't even know there was a mingw tinderbox. 

Comment 13

[[e-mail]]

(In reply to comment #12)
>I'm fine with backing this out of the 1.8 branch if older versions of gcc
>work and we support using them.
I was tempted to hack my w32api.h to report 3.7 ;-)
Given time I could of course try to install gcc/w32api 3.7 on the PC.

>I didn't even know there was a mingw tinderbox.
I set it up because I had no other use for that old NT3.51 workstation ;-)

Comment 14

[cls]

The patch has been backed out of the 1.8 branch.