Closed Bug 885855 Opened 6 years ago Closed 6 years ago

[Build bustage] gfx\2d\RadialGradientEffectD2D1.h(9) : fatal error C1083: Cannot open include file: 'd2d1_1.h': No such file or directory

Categories

(Core :: Graphics, defect, blocker)

x86_64
Windows 7
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: mayhemer, Assigned: Callek)

References

Details

Attachments

(2 files, 1 obsolete file)

No description provided.
For info (as detected by msvc-10.bat):
- building with express 10
- win sdk v 7.0a
- platform sdk v 4
http://msdn.microsoft.com/en-us/library/windows/desktop/dd317121%28v=vs.85%29.aspx

d2d1_1.h 	Defines C and C++ versions of the primary Direct2D API for Windows 8 and later.

I'm on Win7...  

Looks like the condition here is wrong: https://hg.mozilla.org/projects/gum/diff/53b1c9358b18/gfx/2d/moz.build#l1.12
...for those that got stuck.
(In reply to Honza Bambas (:mayhemer) from comment #2)
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd317121%28v=vs.
> 85%29.aspx
> 
> d2d1_1.h 	Defines C and C++ versions of the primary Direct2D API for Windows
> 8 and later.
> 
> I'm on Win7...  
> 
> Looks like the condition here is wrong:
> https://hg.mozilla.org/projects/gum/diff/53b1c9358b18/gfx/2d/moz.build#l1.12

It doesn't matter what you're building on, what matters is the SDK you're building with. The 06020000 check is meant to make sure the file only gets built if you have the Windows 8 SDK. Technically in the ideal world everyone would update to this SDK but we're not in an ideal world, that's why the check was added.

I don't have a machine with the Windows 7 SDK anymore. It would be interesting to know what your MOZ_WINSDK_MAXVER says and why it thinks you have the Windows 8 SDK?
same problem. MOZ_WINSDK_MAXVER in config.status is 0x0x06010000 and 0x06010000 . 

I have vs2012 installed, so windows 8 sdk is there, but the build system choose the VC 2010 built-in SDK.
(In reply to zhoubcfan from comment #5)
> same problem. MOZ_WINSDK_MAXVER in config.status is 0x0x06010000 and
> 0x06010000 . 
> 
> I have vs2012 installed, so windows 8 sdk is there, but the build system
> choose the VC 2010 built-in SDK.

This is a known bug, you should update your mozilla-build to fix that I think. (maybe you need to install the 'real' Windows 8 SDK). I think I understand what the problem is now, that 0x shouldn't be in there just yet, probably a simple fix to Configure.in.
Attached patch Attempted fix (obsolete) — Splinter Review
Could you try this fix? It seems unlike TARGETVER, MAXVER -will- have 0x in there by default. This should hopefully fix the problem.
Comment on attachment 766222 [details] [diff] [review]
Attempted fix

Doesn't WFM. I have the following config settings in the respective files with the patch applied and a full clobber local build:

mozilla-config.h:
MOZ_WINSDK_MAXVER=0x06010000

config.cache:
ac_cv_winsdk_maxver=${ac_cv_winsdk_maxver=0x06010000}

config.status:
(''' MOZ_WINSDK_MAXVER ''', r''' 0x06010000 '''),

I know hardly anything about moz.build, but could it be that the comparison in gfx/2d/moz.build doesn't work as expected? Maybe CONFIG['MOZ_WINSDK_MAXVER'] is a string and needs to be converted before doing a comparison?
Comment on attachment 766222 [details] [diff] [review]
Attempted fix

>-    if CONFIG['MOZ_WINSDK_MAXVER'] >= 06020000:
>+    if CONFIG['MOZ_WINSDK_MAXVER'] >= 0x06020000:
I couldn't get this to work, but it did work with >= '0x06020000':
(In reply to neil@parkwaycc.co.uk from comment #9)
> Comment on attachment 766222 [details] [diff] [review]
> Attempted fix
> 
> >-    if CONFIG['MOZ_WINSDK_MAXVER'] >= 06020000:
> >+    if CONFIG['MOZ_WINSDK_MAXVER'] >= 0x06020000:
> I couldn't get this to work, but it did work with >= '0x06020000':

and *this* is probably the correct fix:

Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '0x06020000'
'0x06020000'
>>> '0x06020000' >= 0x06020000
True
>>> '0x06010000' >= 0x06020000
True
>>> '0x06010000' >= '0x06020000'
False
>>> '0x06020000' >= '0x06020000'
True
I can't test this atm, so f? to Jens for testing.  r? to gps since everything I see in this bug makes me think this ought to do it.
Attachment #766222 - Attachment is obsolete: true
Attachment #766557 - Flags: review?(gps)
Attachment #766557 - Flags: feedback?(jh)
Comment on attachment 766557 [details] [diff] [review]
[mozilla-central] attemp 3

Review of attachment 766557 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks a bunch!
Attachment #766557 - Flags: feedback+
Comment on attachment 766557 [details] [diff] [review]
[mozilla-central] attemp 3

WFM, but I think everyone should be aware that this is a string (character) comparison now. It's not actually comparing numbers. I guess as long as the string lengths and "schemes" are equal, the result should be the same.
Attachment #766557 - Flags: feedback?(jh) → feedback+
Attachment #766557 - Flags: review?(gps) → review+
https://hg.mozilla.org/mozilla-central/rev/19c05a3d7d3c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Assignee: nobody → bugspam.Callek
Target Milestone: --- → mozilla24
I think the patch doesn't work. Windows builds on both <https://tbpl.mozilla.org/?tree=Thunderbird-Trunk> and <https://tbpl.mozilla.org/?tree=Thunderbird-Aurora> still fail with mozilla\gfx\2d\RadialGradientEffectD2D1.h(9) : fatal error C1083: Cannot open include file: 'd2d1_1.h': No such file or directory.
(In reply to Stefan Sitter from comment #15)
> I think the patch doesn't work. Windows builds on both
> <https://tbpl.mozilla.org/?tree=Thunderbird-Trunk> and
> <https://tbpl.mozilla.org/?tree=Thunderbird-Aurora> still fail

Maybe the builders need a clobber? After all, m-c's configure.in was changed and I could imagine that the c-c builders don't clobber automatically in that case. I'm not a build system expert, though.
Ok, we forgot to update the bug. It doesn't work for Thunderbird because the Win8SDKs are installed, and the max ver thing picks it up anyway.

For Thunderbird we are working on upgrading to the Win 8 SDK which is bug 869966, but there's a releng bug for that we are waiting on.
(In reply to Mark Banner (:standard8) from comment #17)
> Ok, we forgot to update the bug. It doesn't work for Thunderbird because the
> Win8SDKs are installed, and the max ver thing picks it up anyway.
> 
> For Thunderbird we are working on upgrading to the Win 8 SDK which is bug
> 869966, but there's a releng bug for that we are waiting on.

Is this the problem where mozilla-build is pointing things at the wrong SDK?
You need to log in before you can comment on or make changes to this bug.