similar to: [PATCH] add missing string.h include to cpu.c (for memset())

Displaying 20 results from an estimated 10000 matches similar to: "[PATCH] add missing string.h include to cpu.c (for memset())"

2013 May 01
2
[PATCH] stream.c needs sys/types.h
For definition of off_t type, stream.c needs including sys/types.h. I hit this requirement at least once when compiling against Mac OSX 10.4 SDK. Trivial patch inlined below. --- opusfile/src/stream.c~ +++ opusfile/src/stream.c @@ -14,6 +14,7 @@ last mod: $Id: vorbisfile.c 17573 2010-10-27 14:53:59Z xiphmont $ ********************************************************************/ +#include
2017 Jan 22
7
os/2 support using Watcom
The attached set of patches adds support for OS/2 using Watcom compiler (tested with Open Watcom 1.9). My only interest was building a working dll (the last patch in the set adds a makefile for it), therefore I did not touch other places: If there is interest, I can do so. Regards. -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name:
2014 May 24
2
make dllimport/dllexport attributes work with mingw (and others)
The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------
2016 Dec 06
2
Some additions for the 1.3.2 changelog?
On 12/6/16, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > MauritsVB wrote: > >> I noticed you’ve started compiling the changelog for 1.3.2. > > I had sort of hoped I'd finished :). Seems I was wrong! > >> I have kept track of some of the bigger changes since 1.3.1 although >> admittedly haven’t been on top of it this year. Perhaps some of these
2023 Jun 07
1
How to change the dynamic library project name ogg to libogg?
On 6/7/23, Martijn van Beurden <mvanb1 at gmail.com> wrote: > I've added the following to Windows-MSVC.cmake, which I copied from > Windows-GNU.cmake > > set(CMAKE_IMPORT_LIBRARY_PREFIX "lib") > set(CMAKE_SHARED_LIBRARY_PREFIX "lib") > set(CMAKE_SHARED_MODULE_PREFIX "lib") > set(CMAKE_STATIC_LIBRARY_PREFIX "lib") >
2017 Jan 14
2
unsigned int and FLAC__uint32 are used interchangeably
On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> warnings with platforms (e.g. djgpp) where int32_t is long: > > Is `sizeof int == 4` though? Yes, obviously it is > I couldn't image FLAC working correctly > if it wasn't. > > Erik
2014 May 24
2
make dllimport/dllexport attributes work with mingw (and others)
On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:
2018 Mar 20
1
several tremor patches
Attached several patches that I have been using to the tremor tree. Please review and apply as you see fit. Regards. -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-os.h-change-elif-_WIN32-to-elif-defined-_WIN32.patch Type: text/x-patch Size: 728 bytes Desc: not available URL:
2014 May 25
2
extend visibility attributes usage to osx builds
The attached small configury patch extends visibility attributes usage to darwin (osx) builds. Tested by cross-compiling on a linux host using gcc-.4.0.2 and gcc-4.2.1 against 10.4 and 10.6 SDKs. Regards. -- O.S. -------------- next part -------------- diff --git a/configure.ac b/configure.ac index 6d0fa00..d3c302a 100644 --- a/configure.ac +++ b/configure.ac @@ -395,7 +395,6 @@ if test
2017 Jan 23
4
os/2 support using Watcom
On 01/22/17 02:00 PM, Ozkan Sezer wrote: > Question: Does emx support __declspec(dllexport) so I can adjust > these changes? Because the emx build of the dll seems to have > exported_everything_ :( GCC supports __declspec(dllexport) though it still needs a def file, with no exports. Libtool doesn't currently and as flac uses libtool... Dave
2017 Jan 14
4
unsigned int and FLAC__uint32 are used interchangeably
On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> > Ozkan Sezer wrote: >> > >> >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> >> warnings with platforms (e.g. djgpp) where int32_t is long: >> > >> > Is `sizeof int == 4` though? >> >> Yes, obviously
2014 May 25
2
make dllimport/dllexport attributes work with mingw (and others)
Erik de Castro Lopo wrote: > Ozkan Sezer wrote: > >> My apologies, obviously sent an old testing patch. Correct one is >> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, >> binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) > > lvqcl, > > Can you please validate this new patch? It works, but only if i call ./configure without
2014 May 25
2
replace -Wextra with -W
The attached small configury patch replaces -Wextra with -W in the main CFLAGS and CXXFLAGS assignments. A few lines after them, -Wextra is conditionally added already with XIPH_ADD_CFLAGS([-Wextra]), so this allows build using older compilers. Regards. -- O.S. -------------- next part -------------- diff --git a/configure.ac b/configure.ac index 6d0fa00..cc5a247 100644 --- a/configure.ac +++
2014 May 25
2
XIPH_C_COMPILER_IS_CLANG preventing many flags
XIPH_C_COMPILER_IS_CLANG in configury (commit a6a4b6f) is blocking many flags including the visibility attributes: I guess this needs relaxing, possibly a lot. What incompatibility led to this commit? -- O.S.
2017 Jan 13
2
unsigned int and FLAC__uint32 are used interchangeably
unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850:
2017 Jan 13
1
[PATCH] support nasm coff obj format for djgpp
Attached patch adds support nasm coff obj format for djgpp -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-support-nasm-coff-obj-format-for-djgpp.patch Type: application/octet-stream Size: 1227 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170113/8c51e0dc/attachment.obj>
2017 Jan 13
1
[PATCH] workaround for DJGPP missing wcswidth()
Attached patch works around for DJGPP missing wcswidth() in flac/utils.c:strlen_console() -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-flac-utils.c-strlen_console-workaround-for-DJGPP-mis.patch Type: application/octet-stream Size: 683 bytes Desc: not available URL:
2013 Aug 21
2
PATCH for cpu.c
1) Some time ago all project files for MSVC 6 were removed; it makes sense to remove the code that is necessary only for MSVC 6 and older compilers. --- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400 @@ -285,14 +285,7 @@ # ifdef USE_TRY_CATCH_FLAVOR _try { __asm { -# if _MSC_VER <= 1200 - /* VC6 assembler
2017 Jan 23
1
os/2 support using Watcom
Ozkan Sezer wrote: > Anyways, with the changed exports.h patch, every need should > be met now.. Sorry, which patch is that? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
2014 May 25
1
make dllimport/dllexport attributes work with mingw (and others)
Ozkan Sezer wrote: > flac.exe built with mingw with or without the dllimport/dllexport patch > always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la > in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it > any more or any less dependent on any 'foreign' dlls: the patch doesn't > change the existent situation in that regard. If