779910 - xulrunner builds fail to compile on windows

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[[e-mail] (:bhearsum)]

winEmbed.cpp
e:/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox/_virtualenv/Scripts/python.exe -O /e/builds/moz2_slave/m-cen-w32-xr/build/build/cl.py cl -FowinEmbed.obj -c   -DXPCOM_GLUE -DXPI_NAME=winembed -I/e/builds/moz2_slave/m-cen-w32-xr/build/embedding/tests/winEmbed -I/e/builds/moz2_slave/m-cen-w32-xr/build/embedding/tests/winEmbed -I. -I../../../dist/include  -Ie:/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox/dist/include/nspr -Ie:/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox/dist/include/nss        -TP -nologo -W3 -Gy -Fdgenerated.pdb -wd4800 -we4553 -GR-  -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -Oy -MD            -FI ../../../dist/include/mozilla-config.h -DMOZILLA_CLIENT /e/builds/moz2_slave/m-cen-w32-xr/build/embedding/tests/winEmbed/winEmbed.cpp
winEmbed.cpp

e:/builds/moz2_slave/m-cen-w32-xr/build/embedding/tests/winEmbed/winEmbed.cpp(877) : error C2664: 'SetWindowLongA' : cannot convert parameter 3 from 'nullptr' to 'LONG'

        A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type

make[5]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox/embedding/tests/winEmbed'
make[4]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox'
make[3]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox'
make[2]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-xr/build/obj-firefox'
make[1]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-xr/build'
make[5]: *** [winEmbed.obj] Error 2
make[4]: *** [libs_tier_app] Error 2
make[3]: *** [tier_app] Error 2
make[2]: *** [default] Error 2
make[1]: *** [realbuild] Error 2
make: *** [build] Error 2

Comment 1

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Relevant docs:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms644898(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/cc230349(v=prot.10).aspx

s/nullptr/0/ should work here, and for any similar errors.  I'd write a patch, but I don't have easy access to a Windows machine.

Comment 2

[[e-mail]]

(In reply to Aryeh Gregor from comment #1)
> s/nullptr/0/ should work here, and for any similar errors.  I'd write a
> patch, but I don't have easy access to a Windows machine.

I just tried it and there were no other compile errors.

Comment 3

[Alex Vincent [:WeirdAl]]

Patch coming, based on above comments.  I'll have to try it myself first.  :)

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: patch

This patch fixes the build bustage, but unfortunately I believe that our regression troubles are not over yet.  The --version flag opens a dialog with gibberish for the version field.  Also, --gre-version doesn't output anything at all to stdout, as --help indicates it would.

Comment 5

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Comment on attachment 649028 [details] [diff] [review]
patch

Looks fine to me, but you should get review from an owner or peer.  It might be that some other symbol would be preferable for a LONG_PTR that's equal to 0 -- I don't know the first thing about Windows programming.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 649028 [details] [diff] [review]
patch

I don't know anything about Windows either, sadly, but I think 0 is fine here.

Comment 7

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0a9fd0b1b5bf

Comment 8

[[e-mail]]

Win16 used INT = 16bit, LONG = 32bit, LPVOID = 32bit
Win32 used INT = 32bit, LONG = 32bit, LPVOID = 32bit
Win64 used INT = 32bit, LONG = 32bit, LPVOID = 64bit - oops!

So they had to invent a new type for an integer that could hold an LPVOID.
Thus LONG_PTR was created. It's basically the equivalent to C++11's intptr_t.

Comment 9

[Ryan VanderMeulen (PTO, back 6-April)]

https://hg.mozilla.org/mozilla-central/rev/0a9fd0b1b5bf