[libav-devel] [PATCH 01/10] dxva2/d3d11va: Set _WIN32_WINNT to 0x0602 instead of 0x0600

[Martin Storsjö]

If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.

When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).

Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
---
libavcodec/d3d11va.h | 2 +-
libavcodec/dxva2.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 2163b35..5237119 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -32,7 +32,7 @@

#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif

#include <stdint.h>
diff --git a/libavcodec/dxva2.h b/libavcodec/dxva2.h
index d9017c6..a40e2a5 100644
--- a/libavcodec/dxva2.h
+++ b/libavcodec/dxva2.h
@@ -31,7 +31,7 @@

#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif

#include <stdint.h>

[Martin Storsjö]

This avoids having to manually set _WIN32_WINNT in --extra-cflags
when targeting these API families, which only was necessary to
work around configure setting _WIN32_WINNT to an older version
by default.
---
configure | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index b76f838..9ccd0da 100755
--- a/configure
+++ b/configure
@@ -3789,8 +3789,19 @@ probe_libc(){
# in such new versions and producing binaries requiring windows 7.0.
# Therefore explicitly set the default to XP unless the user has
# set something else on the command line.
+ # Don't do this if WINAPI_FAMILY is set and is set to a non-desktop
+ # family. For these cases, configure is free to use any functions
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)
check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
- add_${pfx}cppflags -D_WIN32_WINNT=0x0502
+ { check_${pfx}cpp <<EOF && add_${pfx}cppflags -D_WIN32_WINNT=0x0502; }
+#ifdef WINAPI_FAMILY
+#include <winapifamily.h>
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+#error not desktop
+#endif
+#endif
+EOF
elif check_${pfx}cpp_condition stddef.h "defined __KLIBC__"; then
eval ${pfx}libc_type=klibc
elif check_${pfx}cpp_condition sys/cdefs.h "defined __BIONIC__"; then

[Jean-Baptiste Kempf]

Post by Martin Storsjö
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)

Why don't you force to 0x0603 in those partition cases?
Wouldn't that be simpler?

With my kindest regards,

[Martin Storsjö]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)

Why don't you force to 0x0603 in those partition cases?
Wouldn't that be simpler?

We could do that as well, but I tried to minimize the number of cflags we
add (even internally within the build system), so if code in general works
without setting _WIN32_WINNT at all (except for the dxva2/d3d11va
overriding, as tweaked in 1/10) I'd rather go that way. But I don't have a
strong opinion here.

// Martin

[Hendrik Leppkes]

Post by Martin Storsjö

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)

Why don't you force to 0x0603 in those partition cases?
Wouldn't that be simpler?

We could do that as well, but I tried to minimize the number of cflags we
add (even internally within the build system), so if code in general works
without setting _WIN32_WINNT at all (except for the dxva2/d3d11va
overriding, as tweaked in 1/10) I'd rather go that way. But I don't have a
strong opinion here.

I agree with that, keeping the CFLAG overrides smaller is generally
best, so LGTM.

[Steve Lhomme]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)

Why don't you force to 0x0603 in those partition cases?
Wouldn't that be simpler?

In <sdkddkver.h> on the WP8.1 SDK (included at the top of <windows.h>) there is:

#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define _WIN32_WINNT 0x0603
#endif

I think depending on the SDK you use it sets the minimum version
already. So when building for WinRT/WP/W10 that shouldn't be an issue.

There's a chance building with clang we may not have such luck.

Post by Jean-Baptiste Kempf
With my kindest regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - [phone]
Sent from my Electronic Device
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Steve Lhomme

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
+ # found in the SDK headers by default. (Alternatively, we could force
+ # _WIN32_WINNT to 0x0602 in that case.)

Why don't you force to 0x0603 in those partition cases?
Wouldn't that be simpler?

#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define _WIN32_WINNT 0x0603
#endif
I think depending on the SDK you use it sets the minimum version
already. So when building for WinRT/WP/W10 that shouldn't be an issue.

Ok, so I take this as consensus that this patch is ok.

// Martin

[Martin Storsjö]

---
configure | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/configure b/configure
index 9ccd0da..96e5f93 100755
--- a/configure
+++ b/configure
@@ -2642,6 +2642,11 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin -symbols"
ar_default="lib"
+ case "$arch" in
+ arm*)
+ as_default="armasm"
+ ;;
+ esac
target_os_default="win32"
# Use a relative path for TMPDIR. This makes sure all the
# ffconf temp files are written with a relative path, avoiding

[Luca Barbato]

Post by Martin Storsjö
---
configure | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 9ccd0da..96e5f93 100755
--- a/configure
+++ b/configure
@@ -2642,6 +2642,11 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin -symbols"
ar_default="lib"
+ case "$arch" in
+ arm*)
+ as_default="armasm"
+ ;;
+ esac
target_os_default="win32"
# Use a relative path for TMPDIR. This makes sure all the
# ffconf temp files are written with a relative path, avoiding

Probably ok.

[Jean-Baptiste Kempf]

Post by Martin Storsjö
---
configure | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 9ccd0da..96e5f93 100755
--- a/configure
+++ b/configure
@@ -2642,6 +2642,11 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin -symbols"
ar_default="lib"
+ case "$arch" in
+ arm*)
+ as_default="armasm"
+ ;;
+ esac
target_os_default="win32"
# Use a relative path for TMPDIR. This makes sure all the
# ffconf temp files are written with a relative path, avoiding

LGTM.

With my kindest regards,

[Janne Grunau]

Post by Martin Storsjö
---
configure | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 9ccd0da..96e5f93 100755
--- a/configure
+++ b/configure
@@ -2642,6 +2642,11 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin -symbols"
ar_default="lib"
+ case "$arch" in
+ arm*)
+ as_default="armasm"
+ ;;
+ esac
target_os_default="win32"
# Use a relative path for TMPDIR. This makes sure all the
# ffconf temp files are written with a relative path, avoiding

ok

Janne

[Martin Storsjö]

This macro identifies whether VFPv3 is available; MSVC defaults
to hardfloat (except for older MSVC versions for CE, targeting
ARMv4).
---
configure | 2 ++
1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 96e5f93..446a786 100755
--- a/configure
+++ b/configure
@@ -4012,6 +4012,8 @@ elif enabled arm; then

if check_cpp_condition stddef.h "defined __ARM_PCS_VFP"; then
enable vfp_args
+ elif check_cpp_condition stddef.h "defined _M_ARM_FP && _M_ARM_FP >= 30"; then
+ enable vfp_args
elif ! check_cpp_condition stddef.h "defined __ARM_PCS || defined __SOFTFP__"; then
case "${cross_prefix:-$cc}" in
*hardfloat*) enable vfp_args; fpabi=vfp ;;

[Luca Barbato]

Post by Martin Storsjö
This macro identifies whether VFPv3 is available; MSVC defaults
to hardfloat (except for older MSVC versions for CE, targeting
ARMv4).
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 96e5f93..446a786 100755
--- a/configure
+++ b/configure
@@ -4012,6 +4012,8 @@ elif enabled arm; then
if check_cpp_condition stddef.h "defined __ARM_PCS_VFP"; then
enable vfp_args
+ elif check_cpp_condition stddef.h "defined _M_ARM_FP && _M_ARM_FP >= 30"; then
+ enable vfp_args
elif ! check_cpp_condition stddef.h "defined __ARM_PCS || defined __SOFTFP__"; then
case "${cross_prefix:-$cc}" in
*hardfloat*) enable vfp_args; fpabi=vfp ;;

Seems fine.

[Janne Grunau]

Post by Martin Storsjö
This macro identifies whether VFPv3 is available; MSVC defaults
to hardfloat (except for older MSVC versions for CE, targeting
ARMv4).
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 96e5f93..446a786 100755
--- a/configure
+++ b/configure
@@ -4012,6 +4012,8 @@ elif enabled arm; then
if check_cpp_condition stddef.h "defined __ARM_PCS_VFP"; then
enable vfp_args
+ elif check_cpp_condition stddef.h "defined _M_ARM_FP && _M_ARM_FP >= 30"; then
+ enable vfp_args
elif ! check_cpp_condition stddef.h "defined __ARM_PCS || defined __SOFTFP__"; then
case "${cross_prefix:-$cc}" in
*hardfloat*) enable vfp_args; fpabi=vfp ;;

ok

Janne

[Martin Storsjö]

---
configure | 1 +
1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 446a786..77eb8f5 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then

elif enabled arm; then

+ enabled msvc && check_cpp_condition stddef.h "_M_ARM >= 7" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

[Luca Barbato]

Post by Martin Storsjö
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 446a786..77eb8f5 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "_M_ARM >= 7" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

Ok.

[Jean-Baptiste Kempf]

Post by Martin Storsjö
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 446a786..77eb8f5 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "_M_ARM >= 7" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

Doesn't that break Windows CE?

If you ever cared about that...

With my kindest regards,

[Martin Storsjö]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 446a786..77eb8f5 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "_M_ARM >= 7" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

Doesn't that break Windows CE?

Ooh, we have a reviewer that actually pays attention!

_M_ARM indicates the arm instruction set version targeted, so we only do
this for armv7 or newer. The old VC compilers for Windows CE target armv4,
so they have _M_ARM == 4.

We could also check _M_ARMT which indicates whether we're building for
thumb. That'd probably be even more correct here I guess.

Post by Jean-Baptiste Kempf
If you ever cared about that...

In theory at least - we still have a mingw32ce fate instance, but I
haven't tried running such code on an actual device for many years.

The latest MSVC version (at least the normal, public ones I've seen) that
had ARM compilers for CE was 2008, and that one defaulted to armv4, until
they went absent and returned with windows phone 8, for armv7.

// Martin

[Jean-Baptiste Kempf]

Post by Martin Storsjö

Post by Jean-Baptiste Kempf
Doesn't that break Windows CE?

Ooh, we have a reviewer that actually pays attention!

<3 :)

Post by Martin Storsjö
_M_ARM indicates the arm instruction set version targeted, so we only do
this for armv7 or newer. The old VC compilers for Windows CE target armv4,
so they have _M_ARM == 4.
We could also check _M_ARMT which indicates whether we're building for
thumb. That'd probably be even more correct here I guess.

I just remembered that CorePlayer was using NEON in WM6 and someone
using Thumb+Neon in WP7.

Post by Martin Storsjö
The latest MSVC version (at least the normal, public ones I've seen) that
had ARM compilers for CE was 2008, and that one defaulted to armv4, until
they went absent and returned with windows phone 8, for armv7.

OK. I guess you can drop it :)
We can also get Martell to add it on clang/arm/mingw.

With my kindest regards,

[Steve Lhomme]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö

Post by Jean-Baptiste Kempf
Doesn't that break Windows CE?

Ooh, we have a reviewer that actually pays attention!

<3 :)

Post by Martin Storsjö
_M_ARM indicates the arm instruction set version targeted, so we only do
this for armv7 or newer. The old VC compilers for Windows CE target armv4,
so they have _M_ARM == 4.
We could also check _M_ARMT which indicates whether we're building for
thumb. That'd probably be even more correct here I guess.

I just remembered that CorePlayer was using NEON in WM6

Yes, it worked at long as you were talking care of the context changes
yourself or no other app was using NEON on the system while you use
it.
#YOLO

Post by Jean-Baptiste Kempf
and someone
using Thumb+Neon in WP7.

Post by Martin Storsjö
The latest MSVC version (at least the normal, public ones I've seen) that
had ARM compilers for CE was 2008, and that one defaulted to armv4, until
they went absent and returned with windows phone 8, for armv7.

OK. I guess you can drop it :)
We can also get Martell to add it on clang/arm/mingw.
With my kindest regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - [phone]
Sent from my Electronic Device
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Martin Storsjö

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 446a786..77eb8f5 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "_M_ARM >= 7" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

Doesn't that break Windows CE?

Ooh, we have a reviewer that actually pays attention!
_M_ARM indicates the arm instruction set version targeted, so we only do this
for armv7 or newer. The old VC compilers for Windows CE target armv4, so they
have _M_ARM == 4.
We could also check _M_ARMT which indicates whether we're building for thumb.
That'd probably be even more correct here I guess.

Post by Jean-Baptiste Kempf
If you ever cared about that...

In theory at least - we still have a mingw32ce fate instance, but I haven't
tried running such code on an actual device for many years.
The latest MSVC version (at least the normal, public ones I've seen) that had
ARM compilers for CE was 2008, and that one defaulted to armv4, until they
went absent and returned with windows phone 8, for armv7.

Also, just for reference, libav doesn't build with the official CE (or
windows mobile) SDKs - it's missing way too much stuff, that mingw32ce
fills in. (And even then, the mingw32ce headers need to be patched for
libav to be buildable.)

// Martin

[Martin Storsjö]

---
Checking if _M_ARMT is defined, instead of checking _M_ARM >= 7.
---
configure | 1 +
1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index d37341e..898205b 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then

elif enabled arm; then

+ enabled msvc && check_cpp_condition stddef.h "defined _M_ARMT" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

[Janne Grunau]

Post by Martin Storsjö
---
Checking if _M_ARMT is defined, instead of checking _M_ARM >= 7.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index d37341e..898205b 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "defined _M_ARMT" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

is it possible to build/run in arm mode? if yes it should be
'enable_weak thumb' to allow --disable-thumb as configure option.

otherwise ok

Janne

[Steve Lhomme]

Post by Janne Grunau

Post by Martin Storsjö
---
Checking if _M_ARMT is defined, instead of checking _M_ARM >= 7.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index d37341e..898205b 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "defined _M_ARMT" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

is it possible to build/run in arm mode? if yes it should be
'enable_weak thumb' to allow --disable-thumb as configure option.

AFAIK Microsoft doesn't have compilers that run on ARM. Only x86 and
amd64. It might be possible with an open source compiler though.

Post by Janne Grunau
otherwise ok
Janne
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Janne Grunau

Post by Martin Storsjö
---
Checking if _M_ARMT is defined, instead of checking _M_ARM >= 7.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index d37341e..898205b 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "defined _M_ARMT" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

is it possible to build/run in arm mode? if yes it should be
'enable_weak thumb' to allow --disable-thumb as configure option.

The C compiler itself only outputs thumb, I haven't seen any option for
targeting arm. For the asm code you could in theory build it in arm mode,
but iirc the linker still doesn't do all the necessary fixups for
interworking.

// Martin

[Janne Grunau]

Post by Martin Storsjö

Post by Janne Grunau

Post by Martin Storsjö
---
Checking if _M_ARMT is defined, instead of checking _M_ARM >= 7.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index d37341e..898205b 100755
--- a/configure
+++ b/configure
@@ -4007,6 +4007,7 @@ elif enabled alpha; then
elif enabled arm; then
+ enabled msvc && check_cpp_condition stddef.h "defined _M_ARMT" && enable thumb
check_cpp_condition stddef.h "defined __thumb__" && enable_weak thumb
enabled thumb && check_cflags -mthumb || check_cflags -marm

is it possible to build/run in arm mode? if yes it should be
'enable_weak thumb' to allow --disable-thumb as configure option.

The C compiler itself only outputs thumb, I haven't seen any option
for targeting arm. For the asm code you could in theory build it in
arm mode, but iirc the linker still doesn't do all the necessary
fixups for interworking.

thanks, patch ok as is then

Janne

[Martin Storsjö]

The static CRT (libcmt.lib, as used by default or with -MT) doesn't
work when targeting these API subsets.

Only do this if no cflags for CRT selection have been specified,
to allow users to override this default if the user knows better.
---
configure | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

diff --git a/configure b/configure
index 77eb8f5..541d6ce 100755
--- a/configure
+++ b/configure
@@ -3460,6 +3460,29 @@ if [ "$cpu" != generic ]; then
add_asflags $cpuflags
fi

+# Set the right default MSVC CRT if necessary
+if enabled_any msvc icl && check_cpp_condition stdlib.h "defined(WINAPI_FAMILY)"; then
+ if check_cpp <<EOF
+#include <winapifamily.h>
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+#error desktop
+#endif
+EOF
+ then
+ for flag in $CFLAGS; do
+ case $flag in
+ -M[TD]*)
+ crtflag=$flag
+ ;;
+ esac
+ done
+ # If targeting the app/phone subsets, add -MD by default if no -MD/-MT flags have been specified
+ if [ -z "$crtflag" ]; then
+ add_cflags -MD
+ fi
+ fi
+fi
+
# compiler sanity check
check_exec <<EOF
int main(void){ return 0; }

[Jean-Baptiste Kempf]

Post by Martin Storsjö
The static CRT (libcmt.lib, as used by default or with -MT) doesn't
work when targeting these API subsets.
Only do this if no cflags for CRT selection have been specified,
to allow users to override this default if the user knows better.

Isn't that dangerous, licenses-wise?

With my kindest regards,

[Martin Storsjö]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
The static CRT (libcmt.lib, as used by default or with -MT) doesn't
work when targeting these API subsets.
Only do this if no cflags for CRT selection have been specified,
to allow users to override this default if the user knows better.

Isn't that dangerous, licenses-wise?

I'm not sure, can you clarify which way you mean?

In the cases where this is supposed to happen at all, you can't
successfully link a binary at all unless you add -MD. (For winphone SDKs,
there's either no libcmt.lib at all, or you can't really link anything
with it.)

I could change this so that it only is added if -M[TD]* is missing, and if
linking actually fails. For WinRT, linking would probably succeed
(although you can't really ship code built that way) with -MT though, so
you'd manually need to enforce -MD anyway - I think?

// Martin

[Martin Storsjö]

Post by Martin Storsjö

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
The static CRT (libcmt.lib, as used by default or with -MT) doesn't
work when targeting these API subsets.
Only do this if no cflags for CRT selection have been specified,
to allow users to override this default if the user knows better.

Isn't that dangerous, licenses-wise?

I'm not sure, can you clarify which way you mean?
In the cases where this is supposed to happen at all, you can't successfully
link a binary at all unless you add -MD. (For winphone SDKs, there's either
no libcmt.lib at all, or you can't really link anything with it.)

To add on this; I guess the license concern is that msvcr*.dll aren't
technically a part of the OS (i.e. shipped along with the app) and thus
normally avoided when shipping e.g. GPL apps. For the winrt/winphone
targets, you don't ship msvcr*.dll with your app but they are considered a
system component, and this is the only case where we'd be auto-enabling
-MD, so I don't think it's an issue here.

// Martin

[Martin Storsjö]

---
After these patches, one can do a build for Windows Phone/ARM with
as little configure flags as this:
--toolchain=msvc --target-os=win32 --enable-cross-compile --arch=arm --cpu=armv7-a --extra-cflags='-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP'
---
configure | 14 ++++++++++++++
1 file changed, 14 insertions(+)

diff --git a/configure b/configure
index 541d6ce..814dfbd 100755
--- a/configure
+++ b/configure
@@ -3481,6 +3481,20 @@ EOF
add_cflags -MD
fi
fi
+ if check_cpp<<EOF
+#include <winapifamily.h>
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_PHONE)
+#error not phone
+#endif
+EOF
+ then
+ # When building for Windows Phone 8.1 with MSVC 2013, one needs to manually add these ldflags.
+ # For Windows Phone 8.0 (MSVC 2012), they aren't needed (but don't hurt either).
+ # Check whether linking succeeds with the user provided flags, if not, try adding these.
+ check_ld <<EOF || check_ldflags -nodefaultlib:kernel32.lib -nodefaultlib:ole32.lib WindowsPhoneCore.lib
+int main(void){ return 0; }
+EOF
+ fi
fi

# compiler sanity check

[Martin Storsjö]

Post by Martin Storsjö
---
After these patches, one can do a build for Windows Phone/ARM with
--toolchain=msvc --target-os=win32 --enable-cross-compile --arch=arm --cpu=armv7-a --extra-cflags='-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP'
---
configure | 14 ++++++++++++++
1 file changed, 14 insertions(+)

Steve, hopefully these patches won't cause any issues when building with
VLC's compiler wrapper script. The one that adds -MD might be a bit messy
since it just checks what's in CFLAGS (and won't know if you have anything
extra automatically added in the wrapper that configure doesn't know of),
but other than that, most of these things should work seamlessly with
existing setups (with lots of hardcoded flags) and allow removing a lot of
the boilerplate flags.

// Martin

[Steve Lhomme]

Post by Martin Storsjö

Post by Martin Storsjö
---
After these patches, one can do a build for Windows Phone/ARM with
--toolchain=msvc --target-os=win32 --enable-cross-compile --arch=arm
--cpu=armv7-a --extra-cflags='-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP'
---
configure | 14 ++++++++++++++
1 file changed, 14 insertions(+)

Steve, hopefully these patches won't cause any issues when building with
VLC's compiler wrapper script. The one that adds -MD might be a bit messy
since it just checks what's in CFLAGS (and won't know if you have anything
extra automatically added in the wrapper that configure doesn't know of),
but other than that, most of these things should work seamlessly with
existing setups (with lots of hardcoded flags) and allow removing a lot of
the boilerplate flags.

No they shouldn't. Also your patch doesn't take in account WinRT which
is a little bit different.

Check https://github.com/robUx4/vlc-msvc/blob/master/wrappers/clwrap#L13

Post by Martin Storsjö
// Martin
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Steve Lhomme

Post by Martin Storsjö

Post by Martin Storsjö
---
After these patches, one can do a build for Windows Phone/ARM with
--toolchain=msvc --target-os=win32 --enable-cross-compile --arch=arm
--cpu=armv7-a --extra-cflags='-DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP'
---
configure | 14 ++++++++++++++
1 file changed, 14 insertions(+)

Steve, hopefully these patches won't cause any issues when building with
VLC's compiler wrapper script. The one that adds -MD might be a bit messy
since it just checks what's in CFLAGS (and won't know if you have anything
extra automatically added in the wrapper that configure doesn't know of),
but other than that, most of these things should work seamlessly with
existing setups (with lots of hardcoded flags) and allow removing a lot of
the boilerplate flags.

No they shouldn't. Also your patch doesn't take in account WinRT which
is a little bit different.
Check https://github.com/robUx4/vlc-msvc/blob/master/wrappers/clwrap#L13

Which ones of those are strictly necessary for libav? When targeting
WinRT, building right now works just fine without adding any extra
ldflags. As long as we don't call any such APIs, one doesn't need to add
e.g. RuntimeObject.lib or any such. The only thing that would be useful is
adding the nodefaultlib entries, but I don't really see why they'd be
necessary here either.

(Also, it feels weird that you're first forcing both ole32.lib and
kernel32.lib and then adding -nodefaultlib to exclude them again.)

Or am I missing anything? I haven't actually tried shipping any WinRT app.

// Martin

[Martin Storsjö]

This is only necessary on MSVC 2010/2012 (and possibly on some
ICL versions). This both avoids an extra hack on newer MSVC
versions, and better documents what the extra compiler option
is used for.
---
configure | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 814dfbd..b67c4b5 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -Dstrtoll=_strtoi64'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -3085,7 +3085,7 @@ probe_cc(){
_flags='-nologo -Qdiag-error:4044,10157'
# -Qvec- -Qsimd- to prevent miscompilation, -GS for consistency
# with MSVC which enables it by default.
- _cflags='-D_USE_MATH_DEFINES -FIstdlib.h -Dstrtoll=_strtoi64 -Qms0 -Qvec- -Qsimd- -GS'
+ _cflags='-D_USE_MATH_DEFINES -Dstrtoll=_strtoi64 -Qms0 -Qvec- -Qsimd- -GS'
elif $_cc --version 2>/dev/null | grep -q ^cparser; then
_type=cparser
_ident=$($_cc --version | head -n1)
@@ -4734,6 +4734,17 @@ elif enabled_any msvc icl; then
fi
# msvcrt10 x64 incorrectly enables log2, only msvcrt12 (MSVC 2013) onwards actually has log2.
check_cpp_condition crtversion.h "_VC_CRT_MAJOR_VERSION >= 12" || disable log2
+ # The CRT headers contain __declspec(restrict) in a few places, but if redefining
+ # restrict, this might break. MSVC 2010 and 2012 fail with __declspec(__restrict)
+ # (as it ends up if the restrict redefine is done before including stdlib.h), while
+ # MSVC 2013 and newer can handle it fine.
+ # If this declspec fails, force including stdlib.h before the restrict redefinition
+ # happens in config.h.
+ if [ $_restrict != restrict ]; then
+ check_cc <<EOF || add_cflags -FIstdlib.h
+__declspec($_restrict) void* foo(int);
+EOF
+ fi
fi

case $as_type in

[Luca Barbato]

Post by Martin Storsjö
This is only necessary on MSVC 2010/2012 (and possibly on some
ICL versions). This both avoids an extra hack on newer MSVC
versions, and better documents what the extra compiler option
is used for.
---
configure | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)

Probably Fine.

lu

[Jean-Baptiste Kempf]

Post by Martin Storsjö
This is only necessary on MSVC 2010/2012 (and possibly on some
ICL versions). This both avoids an extra hack on newer MSVC
versions, and better documents what the extra compiler option
is used for.

LGTM.
With my kindest regards,

[Steve Lhomme]

Post by Martin Storsjö
This is only necessary on MSVC 2010/2012 (and possibly on some
ICL versions). This both avoids an extra hack on newer MSVC
versions, and better documents what the extra compiler option
is used for.

Good thing because setting the WINAPI_FAMILY from the command line was
setting it after including stdlib.h and thus likely including a lot of
windows stuff that are not available on WP/WinRT.

Forced includes are evil.

Post by Martin Storsjö
---
configure | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 814dfbd..b67c4b5 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -Dstrtoll=_strtoi64'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -3085,7 +3085,7 @@ probe_cc(){
_flags='-nologo -Qdiag-error:4044,10157'
# -Qvec- -Qsimd- to prevent miscompilation, -GS for consistency
# with MSVC which enables it by default.
- _cflags='-D_USE_MATH_DEFINES -FIstdlib.h -Dstrtoll=_strtoi64 -Qms0 -Qvec- -Qsimd- -GS'
+ _cflags='-D_USE_MATH_DEFINES -Dstrtoll=_strtoi64 -Qms0 -Qvec- -Qsimd- -GS'
elif $_cc --version 2>/dev/null | grep -q ^cparser; then
_type=cparser
_ident=$($_cc --version | head -n1)
@@ -4734,6 +4734,17 @@ elif enabled_any msvc icl; then
fi
# msvcrt10 x64 incorrectly enables log2, only msvcrt12 (MSVC 2013) onwards actually has log2.
check_cpp_condition crtversion.h "_VC_CRT_MAJOR_VERSION >= 12" || disable log2
+ # The CRT headers contain __declspec(restrict) in a few places, but if redefining
+ # restrict, this might break. MSVC 2010 and 2012 fail with __declspec(__restrict)
+ # (as it ends up if the restrict redefine is done before including stdlib.h), while
+ # MSVC 2013 and newer can handle it fine.
+ # If this declspec fails, force including stdlib.h before the restrict redefinition
+ # happens in config.h.
+ if [ $_restrict != restrict ]; then
+ check_cc <<EOF || add_cflags -FIstdlib.h
+__declspec($_restrict) void* foo(int);
+EOF
+ fi
fi
case $as_type in
--
1.8.1.2
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Steve Lhomme

Post by Martin Storsjö
This is only necessary on MSVC 2010/2012 (and possibly on some
ICL versions). This both avoids an extra hack on newer MSVC
versions, and better documents what the extra compiler option
is used for.

Good thing because setting the WINAPI_FAMILY from the command line was
setting it after including stdlib.h and thus likely including a lot of
windows stuff that are not available on WP/WinRT.

Oh, good catch - I hadn't thought about that either, so that's yet another
reason why this is a good idea to finally get rid of.

// Martin

[Martin Storsjö]

This isn't necessary on MSVC 2015 any longer.
---
configure | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index b67c4b5..ab174f2 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dstrtoll=_strtoi64'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -4747,6 +4747,17 @@ EOF
fi
fi

+for pfx in "" host_; do
+ pfx_no_=${pfx%_}
+ varname=${pfx_no_}cc_type
+ eval "type=\$$varname"
+ if [ $type = "msvc" ]; then
+ check_${pfx}cc <<EOF || add_${pfx}cflags -Dinline=__inline
+static inline int foo(int a) { return a; }
+EOF
+ fi
+done
+
case $as_type in
clang)
add_asflags -Qunused-arguments

[Luca Barbato]

Post by Martin Storsjö
This isn't necessary on MSVC 2015 any longer.
---
configure | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Ok.

[Jean-Baptiste Kempf]

Post by Martin Storsjö
This isn't necessary on MSVC 2015 any longer.

LGTM.
With my kindest regards,

[Janne Grunau]

Post by Martin Storsjö
This isn't necessary on MSVC 2015 any longer.
---
configure | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index b67c4b5..ab174f2 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dstrtoll=_strtoi64'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -4747,6 +4747,17 @@ EOF
fi
fi
+for pfx in "" host_; do
+ pfx_no_=${pfx%_}
+ varname=${pfx_no_}cc_type

the double expansion is not necessary. varname=${pfx%_}cc_type works as
well

Post by Martin Storsjö
+ eval "type=\$$varname"
+ if [ $type = "msvc" ]; then
+ check_${pfx}cc <<EOF || add_${pfx}cflags -Dinline=__inline
+static inline int foo(int a) { return a; }
+EOF
+ fi
+done
+

no pretty but I don't see how it can be better, ok


Janne

[Martin Storsjö]

Post by Janne Grunau

Post by Martin Storsjö
This isn't necessary on MSVC 2015 any longer.
---
configure | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index b67c4b5..ab174f2 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dstrtoll=_strtoi64'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -4747,6 +4747,17 @@ EOF
fi
fi
+for pfx in "" host_; do
+ pfx_no_=${pfx%_}
+ varname=${pfx_no_}cc_type

the double expansion is not necessary. varname=${pfx%_}cc_type works as
well

Ah, yes. I'll fix that, in a separate commit unfortunately since this has
already been pushed.

// Martin

[Martin Storsjö]

This isn't necessary any longer on MSVC 2013.
---
configure | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index ab174f2..5368cf0 100755
--- a/configure
+++ b/configure
@@ -3062,7 +3062,7 @@ probe_cc(){
_ld_lib='lib%.a'
_ld_path='-libpath:'
_flags='-nologo'
- _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dstrtoll=_strtoi64'
+ _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS'
elif $_cc 2>&1 | grep -q Intel; then
_type=icl
_ident=$($_cc 2>&1 | head -n1)
@@ -3085,7 +3085,7 @@ probe_cc(){
_flags='-nologo -Qdiag-error:4044,10157'
# -Qvec- -Qsimd- to prevent miscompilation, -GS for consistency
# with MSVC which enables it by default.
- _cflags='-D_USE_MATH_DEFINES -Dstrtoll=_strtoi64 -Qms0 -Qvec- -Qsimd- -GS'
+ _cflags='-D_USE_MATH_DEFINES -Qms0 -Qvec- -Qsimd- -GS'
elif $_cc --version 2>/dev/null | grep -q ^cparser; then
_type=cparser
_ident=$($_cc --version | head -n1)
@@ -4745,6 +4745,7 @@ elif enabled_any msvc icl; then
__declspec($_restrict) void* foo(int);
EOF
fi
+ check_func strtoll || add_cflags -Dstrtoll=_strtoi64
fi

for pfx in "" host_; do

[Jean-Baptiste Kempf]

Post by Martin Storsjö
This isn't necessary any longer on MSVC 2013.

I agree with the patch, but IIRC, it can still fail on MSVC 2013, if you
don't have the latest version (4).

With my kindest regards,

[Hendrik Leppkes]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
This isn't necessary any longer on MSVC 2013.

I agree with the patch, but IIRC, it can still fail on MSVC 2013, if you
don't have the latest version (4).

Well the configure check will catch any failure, no matter from which
version, so thats fine. Patch LGTM.

[Martin Storsjö]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
This isn't necessary any longer on MSVC 2013.

I agree with the patch, but IIRC, it can still fail on MSVC 2013, if you
don't have the latest version (4).

Hmm, possibly, I might have used that version for testing. (I don't
remember which version I've packaged for my wine setups, where I do most
of the testing.)

Anyway, as long as the test doesn't check for versions but for actual
functionality, this should (hopefully) work regardless what version I
claim in the commit message.

// Martin

[Jean-Baptiste Kempf]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
This isn't necessary any longer on MSVC 2013.

I agree with the patch, but IIRC, it can still fail on MSVC 2013, if you
don't have the latest version (4).

Hmm, possibly, I might have used that version for testing. (I don't remember
which version I've packaged for my wine setups, where I do most of the
testing.)
Anyway, as long as the test doesn't check for versions but for actual
functionality, this should (hopefully) work regardless what version I claim
in the commit message.

Yes. Which is why I said "I agree with the patch".

With my kindest regards,

[Jean-Baptiste Kempf]

Post by Martin Storsjö
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.

Yes.

Post by Martin Storsjö
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).

In theory, those API should work in 601, but as far as headers, it's
probably OK.

With my kindest regards,

[Steve Lhomme]

Post by Jean-Baptiste Kempf

Post by Martin Storsjö
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.

Yes.

Post by Martin Storsjö
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).

In theory, those API should work in 601, but as far as headers, it's
probably OK.

Yes it works. I did most of the work on D3D11VA on Windows 7.

Post by Jean-Baptiste Kempf
With my kindest regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - [phone]
Sent from my Electronic Device
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Hendrik Leppkes]

Post by Martin Storsjö
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).
Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
---
libavcodec/d3d11va.h | 2 +-
libavcodec/dxva2.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 2163b35..5237119 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -32,7 +32,7 @@
#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600

Shouldnt these checks also be updated to increment it if its 0x0600 right now?

Post by Martin Storsjö
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif
#include <stdint.h>
diff --git a/libavcodec/dxva2.h b/libavcodec/dxva2.h
index d9017c6..a40e2a5 100644
--- a/libavcodec/dxva2.h
+++ b/libavcodec/dxva2.h
@@ -31,7 +31,7 @@
#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif
#include <stdint.h>
--
1.8.1.2
_______________________________________________
libav-devel mailing list
https://lists.libav.org/mailman/listinfo/libav-devel

[Martin Storsjö]

Post by Hendrik Leppkes

Post by Martin Storsjö
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).
Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
---
libavcodec/d3d11va.h | 2 +-
libavcodec/dxva2.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 2163b35..5237119 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -32,7 +32,7 @@
#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600

Shouldnt these checks also be updated to increment it if its 0x0600 right now?

It does indeed look strange this way.

Strictly it shouldn't be needed, but we could do that as well just for
consistency. Or scrap this, and hardcode it to 0x0602 in patch 2/10, but I
see you agree with my reasoning there.

So I can change this to consistently use 0x0602 just to make sure it
doesn't look strange. Perhaps also change configure to test with version
0x0602 for the test where it is overridden?

// Martin

[Martin Storsjö]

If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.

When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).

Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
---
Consistently using 0x0602 instead of 0x0600 in all places now.
---
configure | 2 +-
libavcodec/d3d11va.h | 4 ++--
libavcodec/dxva2.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 66edc14..711c2b5 100755
--- a/configure
+++ b/configure
@@ -4272,7 +4272,7 @@ check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss

check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
-check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0600
+check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602

if ! disabled w32threads && ! enabled pthreads; then
check_func_headers "windows.h process.h" _beginthreadex &&
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 2163b35..f5777c2 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -30,9 +30,9 @@
* Public libavcodec D3D11VA header.
*/

-#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
+#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0602
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif

#include <stdint.h>
diff --git a/libavcodec/dxva2.h b/libavcodec/dxva2.h
index d9017c6..ec448a4 100644
--- a/libavcodec/dxva2.h
+++ b/libavcodec/dxva2.h
@@ -29,9 +29,9 @@
* Public libavcodec DXVA2 header.
*/

-#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
+#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0602
#undef _WIN32_WINNT
-#define _WIN32_WINNT 0x0600
+#define _WIN32_WINNT 0x0602
#endif

#include <stdint.h>

[Martin Storsjö]

Post by Martin Storsjö
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).
Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
---
Consistently using 0x0602 instead of 0x0600 in all places now.
---
configure | 2 +-
libavcodec/d3d11va.h | 4 ++--
libavcodec/dxva2.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)

Since this was what was suggested in the previous version of the patch,
I'll take that as an implicit ok for this one.

// Martin