980697 - Pull newer versions of the d3dcompiler dll from installed Windows SDKs

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Kelsey Gilbert [:jgilbert]]

[Previously bug 896762]

Switching to the newer Win8 and Win8.1 Windows SDKs gives us access to d3dcompiler_46 and _47.dll respectively. We should update our build scripts to be able to pull in these newer types.

We should consider dropping support for older versions of the compiler. There are definite reasons we want the newer DLL as opposed to the old one.

I believe we should make _46 the minimum. and remove support for the older DirectX SDK source-location.

Comment 1

[Kelsey Gilbert [:jgilbert]]

Attachment: (from h.rayflood) patch 1: use windows sdk for directx headers and libraries

Comment 2

[u480271]

Not "We should consider dropping support for older versions of the compiler.", but "We should drop support for older versions of the compiler, less than d3dcompiler_46.dll."

Comment 3

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8387289 [details] [diff] [review]
(from h.rayflood) patch 1: use windows sdk for directx headers and libraries

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

::: configure.in
@@ +5694,5 @@
>  dnl = * enabled by default (shipping build); requires explicit --disable to disable
>  dnl ========================================================
>  MOZ_ANGLE_RENDERER=
>  MOZ_DIRECTX_SDK_PATH=
> +MOZ_WINSDK_DIRECTX=

This seems like it should be called MOZ_HAS_WINSDK_WITH_D3D.

@@ +5737,5 @@
> +  case "$MOZ_WINSDK_MAXVER" in
> +  0x0603*)
> +    MOZ_WINSDK_DIRECTX=1
> +    MOZ_D3DX9_VERSION=47
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_$MOZ_D3DX9_VERSION.dll

Don't use MOZ_D3DX9_VERSION here anymore, since it's only relevant to old DX SDK stuff.
Remove the MOZ_D3DX9_VERSION line and set the MOZ_D3DCOMPILER_DLL line explicitly.

Also, the filenames are not uppercase. The files in both the 8.0 and 8.1 SDKs are named "d3dcompiler_NN.dll", where NN is 46 and 47 respective to the versions.

@@ +5762,5 @@
>    fi
>    MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's/.*\([[a-zA-Z]]\)\\:\\\\/\\1\\:\\\\/' | sed 's,\\\\,/,g'`
>  fi
>  
> +if test -n "$MOZ_ANGLE_RENDERER" -a -z "$CROSS_COMPILE" -a -z "$MOZ_WINSDK_DIRECTX"; then

I hate if/test syntax so much.

@@ +5825,5 @@
>          elif test "$GCC" != "yes"; then
>              MOZ_GAMEPAD=
>          fi
> +        if test -n "$MOZ_WINSDK_DIRECTX"; then
> +            MOZ_GAMEPAD=1

Why is this added here? This seems like it should go in a dependent bug.

::: gfx/angle/Makefile.in
@@ +4,5 @@
>  
>  ifdef MOZ_ANGLE_RENDERER
>  
>  libs::
> +ifndef MOZ_WINSDK_DIRECTX

Prefer ifdef to ifndef in this case. Switch the order here, since we want to (eventually) deprecate usage of the DX SDK. [1]

@@ +9,5 @@
>  ifdef MOZ_D3DCOMPILER_CAB
>  	expand '$(MOZ_D3DCOMPILER_CAB)' -F:$(MOZ_D3DCOMPILER_DLL) '$(DIST)/bin'
>  endif
> +else
> +	cp -p "$${WINDOWSSDKDIR}/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

Why $${WINDOWSSDKDIR} instead of $(WINDOWSSDKDIR)?

::: gfx/angle/src/libEGL/Makefile.in
@@ +20,1 @@
>  CXXFLAGS += -I'$(MOZ_DIRECTX_SDK_PATH)/include'

Do we really need this anymore, if it's already in config.mk?

@@ +28,5 @@
>  OS_LIBS += -ld3d9 -llibGLESv2
>  
>  else
>  
> +ifndef MOZ_WINSDK_DIRECTX

[1]

::: gfx/angle/src/libGLESv2/Makefile.in
@@ +27,5 @@
>  OS_LIBS += -ld3d9 -ldxguid
>  
>  else
>  
> +ifndef MOZ_WINSDK_DIRECTX

[1]

::: toolkit/library/Makefile.in
@@ +110,5 @@
>  EXTRA_DSO_LDOPTS += $(call EXPAND_LIBNAME_PATH,gkmedias,$(DIST)/lib)
>  
>  ifdef MOZ_WEBRTC
>  ifeq (WINNT,$(OS_TARGET))
> +ifndef MOZ_WINSDK_DIRECTX

[1]

@@ +243,5 @@
>  OS_LIBS += $(call EXPAND_LIBNAME,uiautomationcore runtimeobject)
>  endif
>  ifdef MOZ_GAMEPAD
>  ifndef GNU_CC
> +ifndef MOZ_WINSDK_DIRECTX

[1]

Comment 4

[Kelsey Gilbert [:jgilbert]]

(In reply to Dan Glastonbury :djg :kamidphish from comment #2)
> Not "We should consider dropping support for older versions of the
> compiler.", but "We should drop support for older versions of the compiler,
> less than d3dcompiler_46.dll."

Sure, that's a good step. We really want to always use the same one, though, so eventually, we should wean people off 8.0 and onto 8.1 SDK.

Comment 5

[Masatoshi Kimura [:emk]]

Dropping d3dcompiler_43 support means dropping Win7 SDK support because d3dcompiler > 46 is bundled with Win SDL > 8.0 and no standalone DXSDK is available anymore.
According to the MDN doc, We are supposed to support Win7 SDK.
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites
Although I don't disagree with dropping support for Win7 SDK, it should be announced somewhere, at least.

(In reply to Jeff Gilbert [:jgilbert] from comment #4)
> so eventually, we should wean people off 8.0 and onto 8.1 SDK.

Please update our infra first :) The tbpl is using Win8.0 SDK.

Comment 6

[ABE Hiroki (:hATrayflood)]

Attachment: patch1 rev2: use windows sdk for directx headers and libraries

Comment 7

[ABE Hiroki (:hATrayflood)]

thanks for your review.

(In reply to Jeff Gilbert [:jgilbert] from comment #3)
> Comment on attachment 8387289 [details] [diff] [review]
> (from h.rayflood) patch 1: use windows sdk for directx headers and libraries
> 
> Review of attachment 8387289 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/angle/src/libEGL/Makefile.in
> @@ +20,1 @@
> >  CXXFLAGS += -I'$(MOZ_DIRECTX_SDK_PATH)/include'
> 
> Do we really need this anymore, if it's already in config.mk?
> 
-I'$(MOZ_DIRECTX_SDK_PATH)/include' in config.mk is not worked.
we need -I'$(MOZ_DIRECTX_SDK_PATH)/include' in libEGL/Makefile.in and libGLESv2/Makefile.in

Comment 8

[ABE Hiroki (:hATrayflood)]

Attachment: patch2: mozilla-build: overwrite WINDOWSSDKDIR to windows sdk 8.0 or 8.1 on msvc2010

Comment 9

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8387562 [details] [diff] [review]
patch1 rev2: use windows sdk for directx headers and libraries

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

One more time!

::: configure.in
@@ +5759,5 @@
> +if test -n "$MOZ_ANGLE_RENDERER" -a -z "$CROSS_COMPILE"; then
> +  case "$MOZ_WINSDK_MAXVER" in
> +  0x0603*)
> +    MOZ_HAS_WINSDK_WITH_D3D=1
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_47.dll

"d3dcompiler_47" should be all lower-case.

@@ +5764,5 @@
> +    AC_MSG_RESULT([Found DirectX SDK in Windows SDK 8.1 .])
> +  ;;
> +  0x0602*)
> +    MOZ_HAS_WINSDK_WITH_D3D=1
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_46.dll

"d3dcompiler_46" should be all lower-case.

::: gfx/angle/Makefile.in
@@ +5,5 @@
>  ifdef MOZ_ANGLE_RENDERER
>  
>  libs::
> +ifdef MOZ_HAS_WINSDK_WITH_D3D
> +	cp -p "$(WINDOWSSDKDIR)/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

-fp for --force and --preserve

Comment 10

[ABE Hiroki (:hATrayflood)]

Attachment: patch1 rev3: use windows sdk for directx headers and libraries

(In reply to Jeff Gilbert [:jgilbert] from comment #9)
> Comment on attachment 8387562 [details] [diff] [review]
> patch1 rev2: use windows sdk for directx headers and libraries
> 
> Review of attachment 8387562 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> One more time!
> 
thanks. I did it!

Comment 11

[Kelsey Gilbert [:jgilbert]]

Cool, thanks.

Comment 12

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8388015 [details] [diff] [review]
patch1 rev3: use windows sdk for directx headers and libraries

Let's get review from a build peer.

Comment 13

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8387569 [details] [diff] [review]
patch2: mozilla-build: overwrite WINDOWSSDKDIR to windows sdk 8.0 or 8.1 on msvc2010

Let's get review from a build peer.

Comment 14

[Michael Shal [:mshal]]

Comment on attachment 8387569 [details] [diff] [review]
patch2: mozilla-build: overwrite WINDOWSSDKDIR to windows sdk 8.0 or 8.1 on msvc2010

This part looks fine.

Comment 15

[Michael Shal [:mshal]]

Comment on attachment 8388015 [details] [diff] [review]
patch1 rev3: use windows sdk for directx headers and libraries

>diff --git a/gfx/angle/Makefile.in b/gfx/angle/Makefile.in
>--- a/gfx/angle/Makefile.in
>+++ b/gfx/angle/Makefile.in
>@@ -1,18 +1,22 @@
> # This Source Code Form is subject to the terms of the Mozilla Public
> # License, v. 2.0. If a copy of the MPL was not distributed with this
> # file, You can obtain one at http://mozilla.org/MPL/2.0/.
> 
> ifdef MOZ_ANGLE_RENDERER
> 
> libs::
>+ifdef MOZ_HAS_WINSDK_WITH_D3D
>+	cp -fp "$(WINDOWSSDKDIR)/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

Relying on WINDOWSSDKDIR to be set in the environment here makes me nervous. If it happens to not be set, or the environment changes for whatever reason, this will do the wrong thing. I think we should AC_SUBST(WINDOWSSDKDIR) from configure (perhaps erroring out if it isn't set when MOZ_HAS_WINSDK_WITH_D3D is true).

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL, MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of trying to construct a path in the angle Makefile.in?

Comment 17

[ABE Hiroki (:hATrayflood)]

Attachment: patch1 rev4: use windows sdk for directx headers and libraries

Comment 18

[Michael Shal [:mshal]]

Comment on attachment 8389637 [details] [diff] [review]
patch1 rev4: use windows sdk for directx headers and libraries

Thanks for changing that - looks good!

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

tryserver and land land land!

Comment 20

[Kelsey Gilbert [:jgilbert]]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> trying to construct a path in the angle Makefile.in?

In one case, we need to pull it out of a CAB, and in the other, it's just a straight copy across.

Comment 21

[Kelsey Gilbert [:jgilbert]]

https://tbpl.mozilla.org/?tree=Try&rev=2abd7ce2db8c

I'm testing a build locally to be sure we pull the newer of the choices.

Comment 22

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Jeff Gilbert [:jgilbert] from comment #20)
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> > We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> > MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> > MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> > trying to construct a path in the angle Makefile.in?
> 
> In one case, we need to pull it out of a CAB, and in the other, it's just a
> straight copy across.

Don't care about the CAB version any more.  Just skip copying a d3d compiler DLL in that case, ideally warn that they need to upgrade their SDK.  But we can clean this up afterwards.  The build machines all have the right (8.x) SDK, so it's only individual developers that need to update.  And if they're doing any webgl-related work, they likely have a newer SDK anyway, or can update easily.

Just make sure to update the windows build prereqs page.

Comment 23

[Kelsey Gilbert [:jgilbert]]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #22)
> (In reply to Jeff Gilbert [:jgilbert] from comment #20)
> > (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> > > We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> > > MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> > > MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> > > trying to construct a path in the angle Makefile.in?
> > 
> > In one case, we need to pull it out of a CAB, and in the other, it's just a
> > straight copy across.
> 
> Don't care about the CAB version any more.  Just skip copying a d3d compiler
> DLL in that case, ideally warn that they need to upgrade their SDK.  But we
> can clean this up afterwards.  The build machines all have the right (8.x)
> SDK, so it's only individual developers that need to update.  And if they're
> doing any webgl-related work, they likely have a newer SDK anyway, or can
> update easily.
> 
> Just make sure to update the windows build prereqs page.

Alright, let's do that in a follow-up, so as not to slow this down.

Comment 24

[Kelsey Gilbert [:jgilbert]]

Yep, local clobber pulls in _47.dll for me. :)

Comment 25

[Kelsey Gilbert [:jgilbert]]

Try is not happy:

make.py[5]: Entering directory 'c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle'
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle\Makefile:16:0$ cp -fp "/Redist/D3D/x86/d3dcompiler_46.dll" "../../dist/bin"
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\makefiles\autotargets.mk:59:0$ pymake.builtins mkdir -p '.deps/'
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle\Makefile:16:0: command 'cp -fp "/Redist/D3D/x86/d3dcompiler_46.dll" "../../dist/bin"' failed, return code 1
cp: cannot stat `/Redist/D3D/x86/d3dcompiler_46.dll': No such file or directory
evaluation from c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\recurse.mk:189:53:14:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -C angle libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\recurse.mk:162:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -C gfx libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\rules.mk:599:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\client.mk:398:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -j4 -C obj-firefox' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\client.mk:185:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -f c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/client.mk realbuild' failed, return code 2
program finished with exit code 2

Comment 26

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8389637 [details] [diff] [review]
patch1 rev4: use windows sdk for directx headers and libraries

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

::: configure.in
@@ +5772,5 @@
> +  esac
> +fi
> +
> +if test -n "$MOZ_HAS_WINSDK_WITH_D3D"; then
> +  MOZ_D3DCOMPILER_DLL_PATH="$WINDOWSSDKDIR/Redist/D3D/$MOZ_DIRECTX_SDK_CPU_SUFFIX"

We should require $WINDOWSSDKDIR to not be null in order to set MOZ_HAS_WINSDK_WITH_D3D=1.

Comment 27

[Kelsey Gilbert [:jgilbert]]

There is no WINDOWSSDKDIR in the environment on Try:

environment:
  ALLUSERSPROFILE=C:\ProgramData
  APPDATA=C:\Users\cltbld\AppData\Roaming
  APR_ICONV_PATH=c:/mozilla-build/svn-win32-1.6.3/iconv
  BINSCOPE=C:\Program Files (x86)\Microsoft\SDL BinScope\BinScope.exe
  COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
  COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
  COMMONPROGRAMW6432=C:\Program Files\Common Files
  COMPUTERNAME=W64-IX-SLAVE57
  COMSPEC=C:\windows\system32\cmd.exe
  CVS_RSH=ssh
  DXSDK_DIR=C:\Tools\sdks\dx10\
  EDITOR=emacs.exe --no-window-system
  FP_NO_HOST_CHECK=NO
  HG_SHARE_BASE_DIR=c:/builds/hg-shared
  HOME=c:/Users/cltbld
  HOMEDRIVE=C:
  HOMEPATH=\
  HOSTTYPE=i686
  INPUTRC=C:/mozilla-build/msys/etc/inputrc
  KTS_HOME=C:\Program Files\KTS
  KTS_VERSION=1.19c
  LOCALAPPDATA=C:\Users\cltbld\AppData\Local
  LOG="c:\tmp\buildbot-startup.log"
  LOGNAME=cltbld
  LOGONSERVER=\\W64-IX-SLAVE57
  MACHTYPE=i686-pc-msys
  MAKE_MODE=unix
  MOZBUILDDIR=C:\mozilla-build\
  MOZILLABUILD=C:\mozilla-build\
  MOZ_CRASHREPORTER_NO_REPORT=1
  MOZ_OBJDIR=obj-firefox
  MOZ_SIGN_CMD=python c:/builds/moz2_slave/try-w32-d-00000000000000000000/tools/release/signing/signtool.py --cachedir c:/builds/moz2_slave/try-w32-d-00000000000000000000/signing_cache -t c:/builds/moz2_slave/try-w32-d-00000000000000000000/token -n c:/builds/moz2_slave/try-w32-d-00000000000000000000/nonce -c c:/builds/moz2_slave/try-w32-d-00000000000000000000/tools/release/signing/host.cert -H signing4.srv.releng.scl3.mozilla.com:9110 -H signing5.srv.releng.scl3.mozilla.com:9110 -H signing6.srv.releng.scl3.mozilla.com:9110
  MOZ_TOOLS=C:\mozilla-build\\moztools-x64
  MSYSTEM=MINGW32
  NUMBER_OF_PROCESSORS=4
  OLDPWD=c:/Users/cltbld
  OS=Windows_NT
  OSTYPE=msys
  PATH=C:\mozilla-build\nsis-2.46u;C:\mozilla-build\python27;C:\mozilla-build\buildbotve\scripts;C:\mozilla-build\msys\local\bin;c:\mozilla-build\wget;c:\mozilla-build\7zip;c:\mozilla-build\blat261\full;c:\mozilla-build\python;c:\mozilla-build\svn-win32-1.6.3\bin;c:\mozilla-build\upx203w;c:\mozilla-build\emacs-22.3\bin;c:\mozilla-build\info-zip;c:\mozilla-build\nsis-2.22;c:\mozilla-build\nsis-2.33u;c:\mozilla-build\nsis-2.46u;c:\mozilla-build\wix-351728;c:\mozilla-build\hg;c:\mozilla-build\python\Scripts;c:\mozilla-build\kdiff3;c:\mozilla-build\yasm;.;C:\mozilla-build\msys\local\bin;C:\mozilla-build\msys\mingw\bin;C:\mozilla-build\msys\bin;c:\windows\system32;c:\windows;c:\windows\System32\Wbem;c:\windows\System32\WindowsPowerShell\v1.0\;c:\mozilla-build;c:\mozilla-build\python27;c:\mozilla-build\python27\Scripts;C:\mozilla-build\msys\bin;c:\mozilla-build\vim\vim72;c:\mozilla-build\wget;c:\mozilla-build\info-zip;c:\CoreUtils\bin;c:\mozilla-build\buildbotve\scripts;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;c:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\;c:\mozilla-build\moztools-x64\bin;c:\mozilla-build\vim\vim72
  PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
  PROCESSOR_ARCHITECTURE=x86
  PROCESSOR_ARCHITEW6432=AMD64
  PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel
  PROCESSOR_LEVEL=6
  PROCESSOR_REVISION=1e05
  PROGRAMDATA=C:\ProgramData
  PROGRAMFILES=C:\Program Files (x86)
  PROGRAMFILES(X86)=C:\Program Files (x86)
  PROGRAMW6432=C:\Program Files
  PROMPT=$P$G
  PS1=\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ 
  PSMODULEPATH=C:\windows\system32\WindowsPowerShell\v1.0\Modules\
  PUBLIC=C:\Users\Public
  PWD=c:/Users/cltbld
  SHELL=C:/mozilla-build/msys/bin/sh
  SHLVL=1
  SSH_AGENT_PID=2872
  SSH_AUTH_SOCK=C:/Users/cltbld/AppData/Local/Temp/ssh-fYsewp2604/agent.2604
  SYSTEMDRIVE=C:
  SYSTEMROOT=C:\windows
  TEMP=C:/Users/cltbld/AppData/Local/Temp
  TERM=cygwin
  TMP=C:/Users/cltbld/AppData/Local/Temp
  USERDOMAIN=W64-IX-SLAVE57
  USERNAME=cltbld
  USERPROFILE=C:\Users\cltbld
  VS100COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
  WINDIR=C:\windows
  WINDOWS_TRACING_FLAGS=3
  WINDOWS_TRACING_LOGFILE=C:\BVTBin\Tests\installpackage\csilogfile.log
  WIX_351728_PATH=c:/mozilla-build/wix-351728
  XPCOM_DEBUG_BREAK=stack-and-abort
  _=c:/mozilla-build/python/python

Comment 28

[Kelsey Gilbert [:jgilbert]]

I'm looking at falling back to building the WinSDK path from $PROGRAMFILES.

Comment 29

[Kelsey Gilbert [:jgilbert]]

Attachment: patch 3: Update and reorg the ANGLE-related configure code

Comment 30

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 8390143 [details] [diff] [review]
patch 3: Update and reorg the ANGLE-related configure code

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

Looks fine to me.  Let's just kill off the 2010 SDK support after this gecko ships (so, like, next week) and clean up a bunch of this?

Comment 31

[Kelsey Gilbert [:jgilbert]]

ANGLE isn't creating contexts on XP:
https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c

Are we sure _46 still supports XP?

Comment 32

[Masatoshi Kimura [:emk]]

(In reply to Jeff Gilbert [:jgilbert PTO through Mar26] from comment #31)
> ANGLE isn't creating contexts on XP:
> https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c
> 
> Are we sure _46 still supports XP?

According to <http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx>, it doesn't anymore :(
> The actual D3DCompiler_*.DLL in the Windows 8.0 SDK itself only supports
> Windows Vista, Windows 7, and Windows 8.
(snip)
> Note: you can select a Platform Toolset of "v100-sdk80" with the Windows
> 8.0 SDK and Visual Studio 2010 installed to get the VS 2010 compiler
> toolset but using the newer Windows 8.0 SDK header set, but remember
> that version of D3DCompiler_*.DLL does not support runtime use or
> deployment on Windows XP.

Comment 33

[Masatoshi Kimura [:emk]]

So we will have to make MOZ_HAS_WINSDK_WITH_D3D a configurable option. Of course we can't remove _43 support until we drop support for Windows XP :(

Comment 34

[Masatoshi Kimura [:emk]]

Attachment: Make Direct X SDK in Windows SDK opt-in

This is still useful for local builds.
Also fixed a bug in the previous patch.

Try run: https://tbpl.mozilla.org/?tree=Try&rev=bc2321f4baec

Comment 35

[Michael Shal [:mshal]]

Comment on attachment 8394839 [details] [diff] [review]
Make Direct X SDK in Windows SDK opt-in

Looks good to me!

Comment 36

[Masatoshi Kimura [:emk]]

https://tbpl.mozilla.org/?tree=Try&rev=62fb7f57432b

Comment 37

[Masatoshi Kimura [:emk]]

Folded three patches so that bisecting isn't confused.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf2974b3e42e

Comment 38

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/cf2974b3e42e

Comment 39

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Jeff Gilbert [:jgilbert PTO through Mar26] from comment #31)
> ANGLE isn't creating contexts on XP:
> https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c
> 
> Are we sure _46 still supports XP?

Dan tested it, the DLLs work fine.  Maybe there's something that's missing, but we should find that out in testing..

Comment 40

[Masatoshi Kimura [:emk]]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #39)
> Dan tested it, the DLLs work fine.  Maybe there's something that's missing,
> but we should find that out in testing..

It contradicts with my testing...

Comment 41

[Masatoshi Kimura [:emk]]

D3DCompiler_47.dll has the subsystem version 6.0 in the PE header, so it can't work with WinXP. Rather Dan must have missed something.

Comment 42

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Can you try modifying d3dcompiler_47.dll using editbin, e.g. "editbin /subsystem:WINDOWS,5.01 d3dcompiler_47.dll" and see if it works?  Just to see if there's an actual issue, or just the headers.

Comment 43

[Masatoshi Kimura [:emk]]

Even if it technically works, is it legally allowed?
I would not like to file yet another bug to use this bug for hacking around the copyrighted dll.

Comment 44

[Masatoshi Kimura [:emk]]

The DLL depends on a Vista-only function (_except_handler4_common) anyway.

Comment 45

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Please leave any legal decisions to us, and limit this and other bugs to just technical discussions.  Let's figure out *if* it works, and then we can figure out what to do about that result. .. but it sounds like it doesn't, hrm.  That's a huge pain, since we might end up needing to ship both.  Will figure it out.

Comment 46

[ABE Hiroki (:hATrayflood)]

Please check in patch2 to mozilla-build.

Comment 47

[Masatoshi Kimura [:emk]]

Oops, missed the MozillaBuild 1.9.0 release, sorry :(
https://hg.mozilla.org/mozilla-build/rev/af43db058d60

Comment 48

[Rampage]

MozillaBuild 1.9.0 has not been staged:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/

See https://bugzilla.mozilla.org/show_bug.cgi?id=989312

(In reply to Masatoshi Kimura [:emk] from comment #47)
> Oops, missed the MozillaBuild 1.9.0 release, sorry :(
> https://hg.mozilla.org/mozilla-build/rev/af43db058d60

Comment 49

[Masatoshi Kimura [:emk]]

But sources are already tagged. Can we respin the release?

Comment 50

[Rampage]

Yes, please respin the release. 
Awaiting, further confirmation.

(In reply to Masatoshi Kimura [:emk] from comment #49)
> But sources are already tagged. Can we respin the release?

Comment 51

[Ryan VanderMeulen [:RyanVM]]

Any particular reason nobody felt the need to bring this to my attention earlier? The release is tagged and the tracking bug made it quite clear that release is imminent.

Comment 52

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Oversight, I assume.  Sorry!  Upside of taking it is that it removes a painful build dependency for (new) Windows developers.

Comment 53

[Ryan VanderMeulen [:RyanVM]]

One heck of an oversight to not mark any dependencies or even CC the current package maintainer to a bug filed in a different component about something that you want crammed in at the last second. On 3/25, I posted a note in bug 928594 that I wanted to release by the end of the week. I posted a release candidate on 3/26. After receiving no feedback or indication that something else was still wanted (and there are plenty of people CCed to that bug that are also involved in this one), I tagged it for release on 3/28. How much more time do I need to give people to chime in so I can avoid the "WAIT ONE MORE THING!" comments that even have any sort of validity due to RelEng not getting around to finishing their bug yet.