DirectX SDK not detected on WinXP

RESOLVED FIXED

Status

()

Core
Build Config
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Steve Snyder, Assigned: Joe Drew (not getting mail))

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
The configure script does not correctly extract the DirectX SDK path from the Windows registry.  The string parsed-out from the registry is incorrect, leading to failed files tests when configure / configure.in is run.

This is the existing code:

$ export MOZ_DIRECTX_SDK_REG_KEY=`reg query 'HKLM\Software\Microsoft\DirectX' //s | grep 'Microsoft DirectX SDK' | head -n 1`

$ echo $MOZ_DIRECTX_SDK_REG_KEY
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)

So far, so good.  The next line is the problem:

$ export MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's,  *, ,g' | cut -d' ' -f4-`

$ echo $MOZ_DIRECTX_SDK_PATH
DirectX SDK (June 2010)

That "DirectX SDK (June 2010)" is not a path, it's a fragment of a path.  Below is what works.  Note the modified 'cut' command:

$ export MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's,  *, ,g' | cut -f3-`

$ echo $MOZ_DIRECTX_SDK_PATH
C:\Program Files\Microsoft DirectX SDK (June 2010)

The result of the erroneous parsing of the path is that the test of the header and library files that rely on the correct path failed, disallowing MOZ_ANGLE in the build.
Have I mentioned how much I want to move this all to MozillaBuild? configure should not have to dig around in the registry.
(Reporter)

Comment 2

7 years ago
I'm not submitting a patch for this trivial fix because I assume that the existing detection works for some Windows environments.  For mine, it does not.

Environment:

WinXP Prof./SP3 (x86) with all updates applied
Visual Studio Prof. 2008/SP1 plus security fixes
Windows SDK v7.1 (x86)
DirectX SDK, June 2010
MozillaBuild v1.5.1 + WinSDK v7.1 patch

Seen with Firefox 4.0 RC2 tarball.
@ Steve:

Can you paste the output of:
reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath

@ Ted:

I agree, we should have that in MozillaBuild. Vlad wasn't in favor of that because we don't put the other Windows SDKs in MozillaBuild, but since we only need a few files and they're causing trouble, it seems justified to me.
(Reporter)

Comment 4

7 years ago
(In reply to comment #3)
> @ Steve:
> 
> Can you paste the output of:
> reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath

$ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)
    InstallPath REG_SZ  C:\Program Files\Microsoft DirectX SDK (June 2010)
(Assignee)

Comment 5

7 years ago
Created attachment 522429 [details] [diff] [review]
fix
Assignee: nobody → joe
Attachment #522429 - Flags: review?(ted.mielczarek)
(Assignee)

Comment 6

7 years ago
The problem is that reg.exe outputs tabs, not spaces, so I've substituted the sed for two trs - one to squeeze spaces together, another to substitute spaces for tabs.
(Reporter)

Comment 7

7 years ago
(In reply to comment #5)
> Created attachment 522429 [details] [diff] [review]
> fix

The proposed fix doesn't work for 64-bit installations:

$ export MOZ_DIRECTX_SDK_REG_KEY=`reg query 'HKLM\Software\Microsoft\DirectX' //s | grep 'Microsoft DirectX SDK' | head -n 1`

$ echo $MOZ_DIRECTX_SDK_REG_KEY
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)

$ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | tr -s ' ' | tr "\t" " " | cut -d' ' -f4
C:\Program

The original code parses correctly:

$ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's,  *, ,g' | cut -d' ' -f4-
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)
(Assignee)

Comment 8

7 years ago
We only use the DirectX SDK for ANGLE right now, which isn't supported on 64-bit, so this isn't the end of the world.
(Assignee)

Comment 9

7 years ago
Oh wait - I understand. Doesn't work on a 64-bit OS while building 32-bit programs. I can fix that.
(Assignee)

Comment 10

7 years ago
Comment on attachment 522429 [details] [diff] [review]
fix

Well, crap. I'm going to have to think harder about this.
Attachment #522429 - Attachment is obsolete: true
Attachment #522429 - Flags: review?(ted.mielczarek)
attachment 529575 [details] [diff] [review] should fix this, testing welcome.
(Reporter)

Comment 12

6 years ago
I coped the code from your attachment into a new shell script.  The results are below.

WinXP x64:

$ echo $MOZ_DIRECTX_SDK_REG_KEY
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)

$ /n/GetDXSDK.sh
MOZ_DIRECTX_SDK_REG_KEY=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)
MOZ_DIRECTX_SDK_PATH=    InstallPath    REG_SZ    C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)

WinXP x86
---------

$ echo $MOZ_DIRECTX_SDK_REG_KEY
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)

$ /n/GetDXSDK.sh
MOZ_DIRECTX_SDK_REG_KEY=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010)
MOZ_DIRECTX_SDK_PATH=    InstallPath    REG_SZ  C:\Program Files\Microsoft DirectX SDK (June 2010)

The good news: the correct path is found in both environments.  The bad news: some further clean-up is needed to remove the extraneous leading text in both cases.
Created attachment 531029 [details] [diff] [review]
get MOZ_DIRECTX_SDK_PATH from Environment variable DXSDK_DIR
(In reply to comment #12)
> I coped the code from your attachment into a new shell script.  The results
> are below.

You can't do that :-) the code in my attachment is using m4 escaping of square brackets, at least. You would at least have to replace [[x]] by [x].

(In reply to comment #13)
> Created attachment 531029 [details] [diff] [review] [review]
> get MOZ_DIRECTX_SDK_PATH from Environment variable DXSDK_DIR

If we do that, then we should do that only as a fallback if getting it from the registry didn't work. We want to be able to list the different DirectX SDKs installed and prefer the June 2010 SDK over other versions. See patch from comment 11.
Duplicate of this bug: 656055
Well, the code I submitted as a patch for bug 656055 leaves things working as they do just fixes the issue of Windows/XP using Tabs rather than spaces as delimiters.  Not sure if that is preferable to what is being proposed here or not.
This issue is fixed by the pending patch in bug 648804.
(In reply to comment #16)
> Well, the code I submitted as a patch for bug 656055 leaves things working
> as they do just fixes the issue of Windows/XP using Tabs rather than spaces
> as delimiters.  Not sure if that is preferable to what is being proposed
> here or not.
I decided I like the patch in bug 648804 better.  My patch in bug 656055 just kind of made a kludge more kludgey

.
Oh! Joe just tried my patch in bug 648804 on WinXP and said it didn't work. What give?
(In reply to comment #19)
> Oh! Joe just tried my patch in bug 648804 on WinXP and said it didn't work.
> What give?

I don't get it.  It seems to work for me, once I replaced the DOS line endings with UNIX line endings. ('\r\n' to \'n')

One would think Joe would have gotten past that.  But this works fine for me under Windows/XP, so I don't get it either.
(Assignee)

Comment 21

6 years ago
I'm using the February 2010 DX SDK; I will retest tomorrow with the patch as-is, but running the commands from the patch manually didn't seem to work.
(In reply to comment #21)
> I'm using the February 2010 DX SDK; I will retest tomorrow with the patch
> as-is, but running the commands from the patch manually didn't seem to work.

Oh :-) You can't just copy and paste the commands from the patch into bash, because they are m4-escaped:

  [a-z]  becomes [[a-z]]

(In reply to comment #20)
> I don't get it.  It seems to work for me, once I replaced the DOS line
> endings with UNIX line endings. ('\r\n' to \'n')

Oops. Definitely configure.in needs UNIX line endings. Sorry about that.
Fixed by http://hg.mozilla.org/mozilla-central/rev/962fee06b08e from bug 648804
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.