similar to: Patch : Fix cross-compiling from Linux to windows

Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX

will surgent wrote: > Hello, I was trying to compile Flac on MinGW/Msys but got an error stating > SIZE_T_MAX is undefined. > To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and > made the following change: <snip> > #ifndef SIZE_MAX > # ifndef SIZE_T_MAX > # ifdef _MSC_VER > # define SIZE_T_MAX UINT_MAX > # elif

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to support them? * At

This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-

Dave Yeo wrote: > Another try Actually there are still some issues with this patch, mainly around your changes to incluce/FLAC/ordinals.h. This file is a public header file and hence, your changes: diff --git a/include/FLAC/ordinals.h b/include/FLAC/ordinals.h index 80d055b..dc2dafc 100644 --- a/include/FLAC/ordinals.h +++ b/include/FLAC/ordinals.h @@ -32,10 +32,18 @@

Hi, in include/share/alloc.h there is this section: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX SIZE_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX #endif So, if we are on MSVC and have neither SIZE_MAX nor SIZE_T_MAX, we'll define SIZE_T_MAX to mean SIZE_MAX and SIZE_MAX to mean SIZE_T_MAX. I'm afraid this won't work ... It

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes

To the mailing list this time... On Sat, Mar 6, 2010 at 4:26 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 4:19 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote: >>>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t;

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

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 --------------

On Thu, Sep 03, 2020 at 10:47:13AM +0100, Richard W.M. Jones wrote: > > A simple reproducer is: > > ---------------------------------------------------------------------- > #include <stdio.h> > #include <stdlib.h> > #include <stdint.h> > #include <string.h> > > const char * > copyn (const char *str, size_t n) > { > return strndup

[please CC the llvm mailing list] Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: >> What's that extra code path? >> > > #ifndef _MSC_VER > ... > #else /* _MSC_VER */ > /* Visual C++ doesn't provide standard integer headers, but it does provide > built-in data types. */ > > ... extra code path ... > > #endif Sorry, that doesn't

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

- Replaced blanket #define of 8 & 64 bit types with typedefs for each platform to match 16 & 32 bit types. - Updated existing typedefs for each platform to fix odd values and improve consistency. --- include/opus_types.h | 125 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/include/opus_types.h

FTR, my main concern with this kind of approach is the case where your platform has two compilers, only one of which has stdint.h Jean-Marc On 07/05/2015 11:10 AM, Tanu Kaskinen wrote: > From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> > > Not everyone who includes speexdsp_config_types.h will have a test > which defines those, and if we've chosen to use the stdint

> > What do you want to improve exactly? Do you experience > problems? > not only iterator.h but also DataTypes.h I also put back iterator.h because at the trunk of llvm, iterator.h.in and iterator.h.cmake still there:( My improvement is now we didn't to generate DataTyes.h, we just need to generate config.h, And everything is configured at config.h, but not in seperate files.:)

Hi Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In

From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> Not everyone who includes speexdsp_config_types.h will have a test which defines those, and if we've chosen to use the stdint types at configure time then we know exactly which header(s) are available, so just choose the best one then and generate the header to use it. This patch, including the above text, is copied from a commit

Hi, Integer overflow checks often use divisions, which may hurt performance. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Here's a prototype implementation of two passes that complement -instcombine. They recognize common checking patterns and rewrite them using overflow intrinsics. https://gist.github.com/3429064 https://gist.github.com/3429069 Here goes an example.

I?m almost embarrassed to submit the following patch. ==== cut here ==== --- dovecot-2.2.19/src/lib/bits.h.orig Thu Mar 19 08:42:32 2015 +++ dovecot-2.2.19/src/lib/bits.h Thu Nov 5 15:10:35 2015 @@ -10,7 +10,9 @@ #include <limits.h> #include <stddef.h> -#include <stdint.h> +#ifdef HAVE_STDINT_H +# include <stdint.h> +#endif #define UINT64_SUM_OVERFLOWS(a,