similar to: MSVC 2005/2008 can't compile libFLAC

lvqcl wrote: > > These versions of Visual Studio don't have stdint.h and > > all [u]intNN_t types. But now these types are everywhere > > in FLAC codebase. > > Here is the patch that fixes the problem: > it moves definitions of all [u]intNN_t types from share/compat.h > into new file share/msvc2005_int.h and then includes this file > into all files (via

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

Those checks account for compiler changes/improvements introduced in Visual Studio 2010 that are not present in Visual Studio 2008. I will grab Visual Studio 2012 off of MSDN and make sure everything is OK there. -Ben > Hi Ben, > > Can you please remove the _MSC_VER >= 1600 check? > > _MSC_VER 1600 is set for Visual Studio 2010, which means > that Visual Studio 2012 will

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

Thanks, Erik. This is the delta that should fix everything up. I hope that #include "share/compat.h" is acceptable from the test_streams binary. If not, you can probably change it to FLAC/ordinals.h instead Also don't forget to commit my earlier VERSION="1.3.0" patch. You can add the "pre1" in a normal text editor without risk. I didn't include those

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

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in

Great. I need to correct my statement, the check for _MSC_VER <= 1600 was the culprit, like this case: #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ #include <sys/types.h> /* for off_t */ #if _MSC_VER <= 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ #ifndef fseeko #define fseeko fseek #ifndef fseeko #define fseeko fseek #endif #endif Cheers, Cristian. On

This should be enough to fix it > Great. > > I need to correct my statement, the check for _MSC_VER <= 1600 > was the culprit, like this case: > > #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ > #include <sys/types.h> /* for off_t */ > #if _MSC_VER <= 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ > #ifndef fseeko > #define fseeko

This patch renames flac_internal_CreateFile_utf8() function to grabbag__CreateFile_utf8() and moves it from /src/libFLAC/windows_unicode_filenames.c into src/share/grabbag/file.c This function is not used by libFLAC anyway. After this, it should be possible to compile libFLAC as UWP. In the old code there were 3 different #if conditionals around the code that uses CreateFile_utf8(): 1) #ifdef

Hi Ben, Can you please remove the _MSC_VER >= 1600 check? _MSC_VER 1600 is set for Visual Studio 2010, which means that Visual Studio 2012 will get a lot of errors because _MSC_VER is defined as 1700. Cheers, Cristian. On Wed, Mar 6, 2013 at 5:53 PM, Ben Allison <benski at winamp.com> wrote: > Thanks, Erik. > > This is the delta that should fix everything up. > I hope

On 02/07/12 12:03 am, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> 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. > > Sorry Dave, I can't do that. Or rather sorry, the patch

LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h) conflict with those used by other third-party libraries. Instead of these: #ifdef _MSC_VER typedef __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t;

Have you tried decoding to memory, and encoding from that memory? This technique would avoid file I/O. If you are reluctant to allocate enough memory for the full file (and why not, with a 64-bit system?), then you could implement a FIFO. You would need a semaphore to keep track of the decoder's progress, and multithreaded coding. The decoder would pause, whenever the FIFO gets

On May 24, 2011, at 12:11, David Troendle wrote: > Thanks for the tip, Brian. I did have a version that does > everything in > memory, but only had enough memory to get six threads going. > (Although my > system has 16GB, I have not taken the time to create 64-bit > libraries for > wxWidgets, TagLib, libFLAC, etc.) What's wrong with only 6 threads? Is that just 3

Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the

I am getting large, corrupted native FLAC files when trying to call the encoder from inside the decoder. The metadata in the output file is OK. Is initializing and calling an encoder from inside a libFLAC decoder write callback supported? The encoder is initialized on the first write callback. Environment is Win 7 Ult, 64-bit, VS 2008, libFLAC 1.2.1. Here is some context. The static

--- celt/float_cast.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/celt/float_cast.h b/celt/float_cast.h index ede6574..4892e2c 100644 --- a/celt/float_cast.h +++ b/celt/float_cast.h @@ -90,14 +90,14 @@ #include <math.h> #define float2int(x) lrint(x) -#elif (defined(_MSC_VER) && _MSC_VER >= 1400) && (defined (WIN64) || defined (_WIN64))

When I try to compile the FLAC source I am getting: == --------------------Configuration: libFLAC_static - Win32 Release-------------------- Performing Custom Build Step on ..\..\include\FLAC\ordinals.h.in The system cannot find the file specified. Error executing c:\winnt\system32\cmd.exe. all - 1 error(s), 0 warning(s) == Any ideas why this is happpening? I don't really know what I'm

> I just joined the development team for audacity, a corss platform > open source multitrack audio editor. > > I would like to add support for importing and exporting files in FLAC > format. > > I was wondering if any of you could point me to some documentation > about using libflac to add FLAC support to other programs? > (note to self... write libFLAC documentation