[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] Somewhat wonkier Windows problem
From:       Vadim Pakhnushev <vadim.pakhnushev () oracle ! com>
Date:       2013-05-24 13:20:09
Message-ID: 519F6909.4030706 () oracle ! com
[Download RAW message or body]

Hi,

There is a bug filed for exactly this reason:
http://bugs.sun.com/view_bug.do?bug_id=8008022

I was building JDK 7 and 8 with DXSDK 2010 for almost a year without any 
problems, and I don't see why there should be any, the core DXSDK API 
hasn't changed.
The change proposed by David is almost exactly what I was thinking to 
implement.
In addition, I think we should make this change in the old build system 
as well?

BTW, 2D code is not using DXSDK_LIB_PATH at all, it loads the d3d9.dll 
via LoadLibrary.
The only usage of the lib path I've found is javax.sound jsoundds.dll 
which links dsound.dll.

And I've checked that we can remove DXSDK dependency at all since all 
necessary headers are included in Windows SDK (although officially only 
in SDK 8).
But for conservative approach I would use David's change with addition 
for old build system.
I hope Phil can add something to this discussion.

Thanks,
Vadim

On 24.05.2013 13:41, Anthony Petrov wrote:
> [ adding 2d-dev@ ]
>
> On 05/24/2013 11:23 AM, Erik Joelsson wrote:
>> On 2013-05-23 20:10, David Chase wrote:
>>> One change to add (a by-hand "diff") to
>>> common/autoconf/toolchain_windows.m4 :
>>>
>>>    AC_MSG_CHECKING([for DirectX SDK lib dir])
>>>    if test "x$with_dxsdk_lib" != x; then
>>>      DXSDK_LIB_PATH="$with_dxsdk_lib"
>>>    elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
>>>      DXSDK_LIB_PATH="$dxsdk_path/Lib/x64"
>>> +  elif test -d "$dxsdk_path/Lib/x86"; then
>>> +    DXSDK_LIB_PATH="$dxsdk_path/Lib/x86"
>>>    else
>>>      DXSDK_LIB_PATH="$dxsdk_path/Lib"
>>>    fi
>>>
>>> This allows 32-bit configure with DirectX SDK 2010.
>>> This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't
>>> seen it yet.
>>>
>> Yes, newer directx sdks have that subdir while the only one we support
>> doesn't. That's why I didn't add that check. The 2d team is quite
>> adamant about that being the only working directx sdk and any talk about
>> changing it should be with them, not the build team.
>
> We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may 
> (in theory) cause some differences in  rendering graphics. Note that 
> in practice I don't recall if anyone has ever seen any actual 
> differences. However, when fixing e.g. 2D bugs, it is important that 
> developers use the proper version of DXSDK for their developer builds 
> to make sure they reproduce the actual issue. In all other cases the 
> version of DXSDK doesn't really matter.
>
> I don't see how this translates to DXSDK 2004 "being the only working 
> directx sdk". I believe that the changes proposed by David are 
> reasonable and should be implemented to allow the OpenJDK community 
> build with any version of DXSDK.
>
>
>> If we want to change directx sdk, we should first consider removing the
>> dependency completely since technically, everything that's needed is
>> installed with visual studio and/or the normal windows sdk.
>
> I agree, this is a good idea. And this is exactly something that the 
> 2D team should decide. However, I believe that the above patch could 
> be applied to OpenJDK as an interim solution before the decision is made.
>
> -- 
> best regards,
> Anthony
>
>>
>> /Erik
>>> It built, I ran an applet demo, so some minor success there, too.
>>>
>>> I'm keeping notes on what works.
>>>
>>> More later.
>>>
>>> David
>>>
>>>
>>>

[prev in list] [next in list] [prev in thread] [next in thread]