Created attachment 49510 [details]
Use DirectX 9 with .NET2003

Created attachment 49511 [details]
Always use DirectX 10

Well, the DirectX 10 SDK solution leads to this problem:

d:\w1\tin_ws\avmedia\source\win\framegrabber.cxx(44) : fatal error C1083: Cannot
open include file: 'Amvideo.h': No such file or directory
dmake:  Error code 2, while making '../../wntmsci10.pro/slo/framegrabber.obj'
---* tg_merge.mk *---

ERROR: Error 65280 occurred while making /cygdrive/d/w1/tin_ws/avmedia/source/win

That file existed in the old "Microsoft DirectX 9.0 SDK (April 2005)" version,
but is missing in "Microsoft DirectX SDK (August 2007)" (that is the last DX SDK
that supports .NET2003). The file moved to the Windows SDK, but we cannot use
that because of issue 77980.

@pjanik: It build for you, which versions of the PSDK/DirectX SDK are you using?

In the "Add or Remove Programs", I see Microsoft DirectX 9.0 SDK Update (Summer 2004).

d3dx.lib is located in

/cygdrive/c/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Lib/d3dx.lib

> d3dx.lib is located in
> /cygdrive/c/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Lib/d3dx.lib

Yes, but that is not in the ILIB path. Looking at your winenv.set I don't
see that directory anywhere in any variable. Can you check if you have a
d3dx.lib anywhere else in one of the directories listed in your ILIB variable.

I'm slightly puzzled why that works for you.

Looks like

/cygdrive/e/Microsoft DirectX 9.0 SDK/Lib/d3dx.lib

was used and:

pavel@drogo:~/BuildDir/ooo_SRC680_m236_src> echo $ILIB
.;f:\home\pavel\BuildDir\ooo_SRC680_m236_src\solver\680\wntmsci10.pro\lib;c:\J2SDK1~1.2_0
\lib;c:\PROGRA~1\MICROS~2\lib;c:\PROGRA~1\MICROS~1.NET\SDK\v1.1\lib;c:\PROGRA~1
\MICROS~1.NET\Vc7\lib;e:\MICROS~1.0SD\lib
pavel@drogo:~/BuildDir/ooo_SRC680_m236_src> 

Ahh, that explains it. My slightly newer "Microsoft DirectX 9.0 SDK (April
2005)" does not have that library anymore, only d3dx9.lib. M$ seems to have
dropped that library in later versions.

@thb: Do you need DX10? If not, I would propose to use DirectX 9 for both
.NET2003 and .NET2003 and open an issue to switch to DirectX 10 and the Windows
(Vista) SDK (issue 77980) in one change.

I volunteer to do the configure changes and the testing, but it would be nice
if Oliver could look at the remaining issues with the Windows SDK in the 2.4
timeframe.  (Is it possible to use the .NET2003/2005 compiler and a current
Windows SDK to avoid the ADO/winres.h problems?)

Okay, to shed some light on this: the d3dx10.lib is clearly a typo, should be
d3dx9.lib (like for SHL2STDLIBS below). 

BUT: it's currently NOT an option to axe the SHL1STDLIBS += d3dx.lib line,
because that'll kill support for Win9x and true DirectX5. We need to figure out
a distinctive element in the environment (obviously, the compiler rev didn't
suffice) to keep this working somehow for Hamburg buildenv.

Apart from that: I'd rather stay out of this tangled mess. ;-)

Thorsten, can you elaborate on the Win9x / true DirectX5 statement. Does that
mean that an OOo build with .NET2005 and newer is not working on Win9x anymore?
(because d3dx9.lib, well currently d3dx10.lib is used).

How does this fit with Martins wish to axe .NET2003 and thereby the use of
d3dx.lib.

Keeping it buildable within the Hamburg environment is one thing, but we also
need a consistent set of prerequisites for the OOo environment. (And relying
on DirectX SDKs from 2004 does not seem a feasible option.

Switching to .NET2005 / Vista SDK is not an option for the 2.4 codeline (i77980).

@vq: yep, it seems that the 2005er compiler + SDK is unable to produce
DX5-compatible binaries. From what I've heard, we might drop the Win9x support
for 3.0, which would then quite nicely fit in with switching the compiler.

But for today, we need a stop-gap solution that maintains compatibility...
...obo, any distinction I could query in the makefile?

Maybe this is an option?

RCS file: /cvs/gsl/canvas/source/directx/makefile.mk,v
retrieving revision 1.2
diff -r1.2 makefile.mk
119a120
> .IF "$(USE_DIRECTX5)"!=""
120a122,125
> .ELSE # "$(USE_DIRECTX5)
> SHL1STDLIBS += d3dx9.lib     # directx 9
> SHL1STDLIBS += dxguid.lib    # directx 9
> .ENDIF # "$(USE_DIRECTX5)

And I'll set USE_DIRECTX5=YES in Hamburg environment.

rev 1.3 commited as MWS fix for SRC680_m237
HTH,
Oliver

setting to fixed.

Created attachment 49554 [details]
DX5 patch for OOo environment

Thanks for the patch!

What I don't like is the fact that now only Hamburg builds are able to run
on W9x. The previous patch should fix that and use the d3dx lib that come
with the .NET2003 compiler. The patch is still untested, I'm going to start
a testbuild once the current build is done.

@Pavel: Can you please test it also (maybe you need to rename your "other"
d3dx.lib for now.)

> What I don't like is the fact that now only Hamburg builds are 
> able to run on W9x.

But it is the directx canvas which we are talking about here, isn't it? And that
is a completely optional extension, isn't it? If somebody otherwise builds his
own OOo but because of a lack of a sufficiently ancient DirextX SDK can't
produce a directx canvas extension that would run on Win9x, she can download the
prebuilt directx extension and use that.

Or am I missing something?

Not all languages are build by Sun, Pavel for example provides a lot more
community builds for other languages.

I would like to avoid to hear "... my official build works on Win9x, but the
version of XYZ does not." It is only about consistency, if Hamburg wants to
be compatible with Win9x, we (community builds) need to provide that too.

Changeing owner to mh.

So would it be easiest if the directx canvas simply wasn't part of the OOo
sources, but a separate download? (But still LGPL licensed, etc.) After all, it
was only recently added (as far as I know), so it can't be that many people are
already very accustomed to it being built together with OOo. Then one couldn't
claim that problems in building the directx canvas is blocking one's build of OOo.

That seems too much effort to me. With my patch everyone that builds with
.NET2003 on windows will create something that runs on Win9x, and is exactly
the same as if build within Hamburg. It's a minimal patch (still untested, but
I am confident that it (or a fixed patch) will solve the problem.

My patch works for an m236 + canvas/source/directx/makefile.mk rev 1.3 .NET2003
build. d3dx.lib was used.

@pjanik: Pavel, can you double check that the patch is safe? I'd like to get it
in the next possible master.

Volker, what exactly should I test?

That with my patch (iz83430_dx5.diff) and either
 m236 + canvas/source/directx/makefile.mk rev 1.3
or
 m237
the build finds a d3dx.lib from
 Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Lib/ .
You might have to "remove" your d3dx.lib from your
 Microsoft DirectX 9.0 SDK/Lib/
directory as M$ removed it from there in more recent DirectX SDKs. Thanks!

vq: I did so. Works ok.

Thank you Pavel.

@rt,obo: Masterfix please ;)

Hi,

I've commited Volkers patch for SRC680_m237.
@vq: verify please.

Oliver

.

Seen in m237.

May I found this problem in 2.3.1? Because my winxp build stopped at same place...

closing