Commits on Source (5)
-
Martin Storsjö authored
This patch has been sent upstream at https://github.com/pupnp/pupnp/pull/387, but hasn't been acted on by upstream yet. In mingw headers, both time.h and sys/time.h define struct timezone and _TIMEZONE_DEFINED - however only one of them, sys/time.h, define gettimeofday. Thus, if time.h had been included before, we'd have _TIMEZONE_DEFINED defined, and we'd omit our own declaration of the gettimeofday function too, leading to calls to an undeclared function. (If the actual sys/time.h header is included, its declaration of the gettimeofday function does conflict with both the declaration and the definition of upnp's gettimeofday, due to details like missing the restrict attribute on pointers. But that issue already existed and is unaffected by this patch.) Since Clang 15 (which still is under development, so this may still change before it's released) [1], implicit function declarations are a hard error by default, when building code in C99 mode (or newer). [1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626 (cherry picked from commit 83d7194d)
89006bde -
Martin Storsjö authored
This patch has been sent upstream at https://gitlab.xiph.org/xiph/icecast-common/-/merge_requests/2 but hasn't been acted upon there yet. When building for a mingw target, HAVE_GETTIMEOFDAY is defined (as the gettimeofday function was found), but the #ifdef _WIN32 #else block never tried to include <sys/time.h> (which provides the declaration) and/or <time.h> for such targets. This caused gettimeofday to be used without a prior declaration. This has been visible as an easily overlooked warning, but Clang 15 changed this into a fatal error by default, when building in C99 mode (or newer). [1] (While Clang 15 still is under development, this may still change before it's released, but the warning is valid in any case.) Decouple including of those headers from the #ifdef _WIN32 #else block and just check their corresponding availability defines. [1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626 (cherry picked from commit 9e095923)
a0517308 -
Martin Storsjö authored
Since Clang 15 (which still is under development, so this may still change before it's released) [1], implicit function declarations are a hard error by default, when building code in C99 mode (or newer). [1] https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626 The upstream zvbi code doesn't seem to have any support for building for Windows at all, therefore not trying to upstream it. On Windows, the <io.h> header is needed for getting declarations of functions like open/read/write/close. The zvbi project has a header of its own, named io.h, and it resides on a path added with -I, so any includes of <io.h> ends up including this header instead of the system header. Therefore, add an #include_next <io.h> which should bring in the system header and its declarations too. Adjust ifdefs to ifdef out larger bits of the code that contained calls to functions that simply don't exist on Windows, like ioctl, munmap etc. Previously, the zvbi library has been built with implicit declarations of those functions, and the static library has had undefined references to them. As long as those object files from the static library haven't been included in the link, this issue has been unnoticed so far. For the function ffs(), which also was undefined on Windows, provide a _BitScanForward based reimplementation. This also resides in a file that doesn't end up included in the end, but for this case it's just as easy to provide a working implementation as it would be to ifdef it out. (cherry picked from commit 68efd7e5)
8260294a -
Martin Storsjö authored
This code seems to be a stale copy of a regex library from glibc, thus not sending the patch further upstream. In some configurations, this library seems to choose not to include standard C headers but declare the functions manually (without a proper prototype though!). In this case, it already declared malloc and realloc, but didn't declare abort and free in the same way. Just add declarations of these functions in the same way - while the most correct path forward would be to actually make it use the proper system headers. (cherry picked from commit 0e836b4e)
7a321fcf -
Martin Storsjö authored
This source file in projectM uses std::bind2nd, which is declared in the <functional> header. Previously it relied on this header being included implicitly. libc++ recently stopped including <functional> transitively in <algorithm> in https://github.com/llvm/llvm-project/commit/a83f4b9cda57c5b3d414ec3bcf9ac891b2ec27e1. Upstream projectM stopped using std::bind2nd in this file in https://github.com/projectM-visualizer/projectm/commit/10faca9abf4c879a63cdf426ddae338620baf238 - thus not trying to upstream the patch. (cherry picked from commit 3c181d46)
4622e243
Showing
- contrib/src/projectM/missing-includes.patch 10 additions, 0 deletionscontrib/src/projectM/missing-includes.patch
- contrib/src/projectM/rules.mak 1 addition, 0 deletionscontrib/src/projectM/rules.mak
- contrib/src/regex/decls.patch 11 additions, 0 deletionscontrib/src/regex/decls.patch
- contrib/src/regex/rules.mak 1 addition, 0 deletionscontrib/src/regex/rules.mak
- contrib/src/shout/rules.mak 1 addition, 0 deletionscontrib/src/shout/rules.mak
- contrib/src/shout/win32-gettimeofday.patch 22 additions, 0 deletionscontrib/src/shout/win32-gettimeofday.patch
- contrib/src/upnp/rules.mak 1 addition, 0 deletionscontrib/src/upnp/rules.mak
- contrib/src/upnp/win32-gettimeofday.patch 12 additions, 0 deletionscontrib/src/upnp/win32-gettimeofday.patch
- contrib/src/zvbi/rules.mak 1 addition, 0 deletionscontrib/src/zvbi/rules.mak
- contrib/src/zvbi/zvbi-win32-undefined.patch 88 additions, 0 deletionscontrib/src/zvbi/zvbi-win32-undefined.patch
contrib/src/projectM/missing-includes.patch
0 → 100644
contrib/src/regex/decls.patch
0 → 100644
contrib/src/shout/win32-gettimeofday.patch
0 → 100644
contrib/src/upnp/win32-gettimeofday.patch
0 → 100644
contrib/src/zvbi/zvbi-win32-undefined.patch
0 → 100644