Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
In WinRT mode, we use CreateThread instead of _beginthreadex.
CreateThread takes a LPTHREAD_START_ROUTINE function pointer,
which has got the signature DWORD WINAPI ThreadProc(LPVOID).
_beginthreadex takes a function with the signature
unsigned __stdcall func(void *).
DWORD is defined as an unsigned long, which is different type
from unsigned int, even if they have the same size on Windows.
This fixes build failures with Clang 16 and newer, where function
pointer type mismatches are a fatal error by default.
Signed-off-by: Martin Storsjö <martin@martin.st>
This removes the XP compatibility code, and switches entirely to SWR
locks, which are available starting at Windows Vista.
This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.
Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK.
Made appropriate changes to be able to successfully
build C++ files using a Visual C++ build on Windows.
Based on an earlier patch by Kyle Schwarz.
Comments:
-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
get it to build when it is being included in a C++ file and built
with Visual C++. This is mostly a copy of Kyle Schwarz's patch as
described above.
-- configure:
a) Now calling set_ccvars CXX to cause the various CXX_ variables to
be setup properly. For example, with MSVC (Microsoft Visual C++),
this causes CXX_O to be set to -Fo$@ instead of using the default
value. The default value does not work with Visual C++. This
change will also have the impact of correcting CXX_O (and possibly
CXX_C) for other compilers, although this is really only relevant
for the Intel compiler, in addition to MSVC.
b) Now using cl for the C++ compiler for the MSVC toolchain. This is
currently only relevant for building the
Blackmagic/Decklink-related files under avdevice.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '407ac22322e5ce67996ec54ef619cafa4c9ceb78':
w32pthreads: Map MemoryBarrier to __sync_synchronize on mingw
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
This removes the requirement of calling w32thread_init before being
able to use the threading primitives.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The emulation uses native InitOnce* APIs on Windows Vista+, and a
lock-free/allocation-free approach using atomics and spinning for
Windows XP.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Wrap the function calls in a similar fashion to how it's being done
with the critical section API.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This silences warnings about passing arguments from incompatible pointer type
when targeting Windows Vista or newer.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Wrap the function calls in a similar fashion to how it's being done
with the critical section API.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
This silences warnings about passing arguments from incompatible pointer type
when targeting Windows Vista or newer.
Tested-by: Matt Oliver <protogonoi@gmail.com>
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '6baeadd11083774ebd823dd5e1a744c2150a3bfc':
w32pthreads: Mark functions in compatibility wrapper as av_unused
Conflicts:
compat/w32pthreads.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This avoids annoying warnings about unused functions. The compatibility
wrapper is designed to provide a complete (stub) API, so some functions
being unused by some files is natural and no reason for a warning.
* commit '428b0578c64241fc677fed7083cc8fe65e10f32e':
w32threads: Use newer thread synchronization functions when targeting Vista
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When explicitly targeting Vista or newer (which only happens if the
caller explicitly sets _WIN32_WINNT to a high enough value via the
extra cflags option - otherwise configure script sets
-D_WIN32_WINNT=0x0502), we already unconditionally link to the
ConditionVariable functions, since 4622f11f9.
Similarly use the newer -Ex versions of CreateEvent, CreateSemaphore,
InitializeCriticalSection and WaitForSingleObject, that all appeared
in Vista. When building Windows Store applications, the older versions
of these functions aren't available, only the -Ex functions. When
doing such a build, the user can set -D_WIN32_WINNT=0x0600 to
forcibly use the newer functions instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'ef51692a49d58963966adca55c62da9c34c3c7e1':
Revert "w32pthread: help compiler figure out undeeded code"
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4332bf98dc051fd1ffbd9d4ddc1c5e55790c96f1':
w32threads: Don't use function pointers when linking directly to newer APIs
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4622f11f9c.
The compiler should be able to do the dead code elimination now
without this when the cond_* names point directly to the real
functions instead of to local function pointers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the call overhead slightly. More noticeably, it
restores the earlier (unintended?) feature that condition variable
functions work just fine even if w32thread_init() hasn't been called.
This was broken as a side effect of 4622f11f9, if explicitly targeting
Vista+.
This makes w32threading work in VP8 again, if targeting Vista+.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '4622f11f9c83db8a2e08408c71ff901826ca652c':
w32pthread: help compiler figure out undeeded code
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The emulation code is not needed when targetting Vista+
This helps getting rid of CreateSemaphore symbol, which is
forbidden in Windows Store apps.
Signed-off-by: Martin Storsjö <martin@martin.st>