178392 - Build failed with August 2002 MS Platform SDK

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Dan Potter]

When I attempted to build Mozilla using the August 2002 PSDK, I ran into a
problem when compiling the mailnews MAPI hooks.  This problem turned out to be
because TARGET_IS_NT50_OR_LATER was not being defined setting of an #error in
the code, which turned out to be because my copy of rpc.h was expecting
_WIN32_WINNT to be set to either 0x500 for Windows 2000 or 0x510 for Windows XP.

Adding an AC_DEFINE(_WIN32_WINNT, 0x500) line to configure.in caused the build
to complete successfully after rerunning autoconf (and appears to have created a
working executable, with MAPI possibly working - although I'm unsure).

I have a patch which might autodefine the correct _WIN32_WINNT variable on
Windows 2000 and Windows XP, although I'm not completely sure this is the
correct solution - since the actual file causing the error is a generated .C
file generated by MIDL.  It's possible the real error is in the generated
dependancy on having _WIN32_WINNT set to either 0x500 or 0x510.

The exact generated error block in the generated source is:

#if !(TARGET_IS_NT50_OR_LATER)
#error You need a Windows 2000 or later to run this stub because it uses these
features:
#error   /robust command line switch.
#error However, your C/C++ compilation flags indicate you intend to run this app
on earlier systems.
#error This app will die there with the RPC_X_WRONG_STUB_VERSION error.
#endif

Hopefully someone can decide whether this is a bug or just something screwy I
did to my build environment:

Latest Cygwin and required packages, source pulled using Cygwin CVS
MSVC 6.0 SP5 with Processor Pack
MS PSDK August 2002

Comment 1

[Dan Potter]

Attachment: Patch to configure.in

This is the patch I used to get my build to compile.  I'm not completely sure
this is the Right Thing to do, but I figured since it occured and seems to work
on my machine I might as well send it in.

Comment 2

[hacker formerly known as [e-mail]]

The problem is that the platform sdk puts its paths before the standard vc paths
and its version of midl.exe has additional requirements that we currently do not
support.

Comment 3

[Dan Potter]

I'm going to send an e-mail to the maintainer of the Win32 build instructions so
that he can include this information in his "common build problems" list of
instuctions - there have to be other people out there using updated PSDKs which
will run into this problem.

From what you've said, the real stop-gap solution would be to add a
configuration option to specify the exact MIDL to be used instead of allowing
the path to dictate it, or to tell people not to include the PSDK SetEnv.bat
variables in their build environment.  (It's also possible to re-execute
VCVARS32.bat after running SetEnv.bat, since both put themselves first in the
path for some reason.  Although this causes you to have a path of VC6;PSDK;VC6
which probably would be too long under DOS-based Windows build environments.)

This info is based on using "which midl" after altering the Cygwin startup
environment; YMMV.

Unfortunately, I need the updated SDK for other development, so not using it
isn't really an option for me.  Although honestly, it doesn't really surprise me
that updated Microsoft build tools find a way to remove compatibility with "old"
MS operating systems...

Comment 4

[hacker formerly known as [e-mail]]

What's the version string of the PSDK midl compiler?  I think I'm going to just
add a test that limits us to using the standard MSVC6 or 7 versions of the binary.

Comment 5

[Peter Lubczynski]

I've got version 6.00.0347 at home which works. But I've got version 6.00.0359
at work which doesn't.

Comment 6

[hacker formerly known as [e-mail]]

6.00.0347 is the version that comes with .NET studio.  The VC6SP5 version is
5.01.0164.  Should we limit it to those 2 specific versions or allow all major
version number 5 revisions and limit major version number 6 revisions to <=
6.00.0347?  The latter assumes that the version numbers are truly sequential and
this feature creep didn't occur in other minor versions.

Comment 7

[hacker formerly known as [e-mail]]

This should be fixed by the checkin for bug 164646.  We expect to build with
midl.exe version 5.xx or 6.00.0347. If you have some other version, configure
will fail.  You can specify the midl executable by setting MIDL in your
mozconfig file like such:

MIDL='c:/Program Files/Microsoft Visual Studio/VC98/bin/midl'

Comment 8

[Dan Potter]

In case anyone wants to know, I encountered this with MIDL version 6.00.0361, so
the August PSDK contains an even "newer" version of MIDL.  (I think MIDL is in
the common PSDK install also, meaning anyone who installs any new SDK using the
PSDK update will wind up with an incompatible MIDL as well.  I'm not going to
bother to check, as long as it can be solved using MIDL=/path, it's fixed for
most installs.)

Comment 9

[Stephen Walker]

*** Bug 179973 has been marked as a duplicate of this bug. ***

Comment 10

[Alec Flett]

Attachment: I like this better

This version checks for the MIDL version 6.00.0359 - I don't have problems
building with the July 2002 PSDK, aside from the xpinstall wizard issues. I
don't see why we have to drop support for the PSDK...

Comment 11

[hacker formerly known as [e-mail]]

Well, technically, we never had support for the SDK versions of the tools to
begin with.  Some of them just happened to work because they didn't introduce
any additional requirements and we didn't have any version checks to enforce our
build requirements.  Now, they don't and we do.  Besides, Peter said that
6.00.0359 was failing for him.  So if one copy works and the other fails,
there's something screwy going on and I'd rather stick with the current solution
than attempt to wrap my head around MS logic.

Comment 12

[Alec Flett]

I see supporting the PSDK as one step closer to building mozilla on non-MS
compilers.. I don't see why we should have to explicity make it stop working
altogether. 

(and if we're going to be like that, we should at least put a better note in
configure, like "The MS Platform SDK is not supported for building mozilla." -
otherwise I had no idea why my midl compiler wasn't supported..)

Comment 13

[hacker formerly known as [e-mail]]

When attempting to build on non-MS compilers on win32, I think the MS PSDK is
the least of our worries (see bug 134113).  You say that this version works when
two other people report that it doesn't.  Are you building with activex,
accessibility & mailnews (mapi & palmsync)? Those are the only components that
actually use midl.

I'll append this message to the error:

"Set MIDL in your \$MOZCONFIG file to point to a supported version of midl as
specified in bug 178392#c7."

Is the MS PSDK the only other place to get midl.exe?

Comment 14

[Alec Flett]

I'm building all the default stuff, so if it includes that then yes. Now, behind
the PSDK in my include path is of course Visual Studio, so I'm getting mfc, atl,
etc.. just further down the path.

Comment 15

[Peter Lubczynski]

So I tried a fresh tree running with WinXP 32-bit debug environment variables
set through the shortcut the July 2002 PSDK left in my start menu. After hacking
./configure to work with my midl version, I get the same error building widget:

ISimpleDOMNode_p.c
c:/builds/testPSDK/mozilla/widget/src/windows/expose/ISimpleDOMNode/ISimpleDOMNode_p.c(81)
: fatal error C1189: #error :  You need a Windows 2000 or later to run this stub
because it uses these features:
make[6]: *** [ISimpleDOMNode_p.obj] Error 2
make[6]: Leaving directory
`/cygdrive/c/builds/testPSDK/mozilla/widget/src/windows/expose/ISimpleDOMNode'