similar to: [PATCH 1/2] Fix mistyped variable name

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 ||

Hi all, I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if this is the right place to submit patches, but someone suggested this on the apparently dead SourceForge patch tracker. The first two are quite straight forward: - The ICL patch fixes a typo in bitmath.h and adds FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c. - The Ogg patch replaces

1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 1400) is always true and can be removed. 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so FLAC__clz_soft_uint32() should have the same argument type. 3) The patch removes unnecessary parentheses around 'word' variable. 4) It also replaces "sizeof(FLAC__uint32) * CHAR_BIT - 1 -

More or less detailed explanation of this patch. 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is a pointer to unsigned long (4-byte int). However _BitScanReverse64() is called with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug and this patch changes the type of idx variable inside FLAC__bitmath_ilog2_wide() from FLAC__uint64 to unsigned long. The type of idx

Hello, I had some difficulties compiling the current git ( http://git.xiph.org/?p=flac.git;a=commit;h=a7e3705d051bafd1cae90f6605287cc1d9f2a18d ) using the Ubuntu 12.04 supplied MinGW32 cross compiler: I configured the FLAC build with --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux but ran into several linker problems. Are these options somehow wrong? It worked fine when

lvqcl wrote: > More or less detailed explanation of this patch. I've applied part of that patch. > 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is > a pointer to unsigned long (4-byte int). On windows, yes, unsigned long is 4 bytes for both 32 and 64 bit versions. This is not true for most Unices. > However _BitScanReverse64() is called with a pointer to

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Hi all, I couldn't find any documentation on this, but was wondering if people here knew what this inline asm means: unsigned __ctz_x = val; unsigned __ctz_c; __asm__ ("{cntlz|cntlzw} %0,%1" : "=r" (__ctz_c) : "r" (__ctz_x & -__ctz_x)); I'm assuming that "{cntlz|cntlzw}" indicates

Hello, While building from git, I'm getting the following failure (help please): CC ogg_mapping.lo CCLD libFLAC.la Creating library file: .libs/libFLAC.dll.a .libs/bitreader.o: In function `FLAC__clz_soft_uint32': ./include/private/bitmath.h:46: multiple definition of `_FLAC__clz_soft_uint32' .libs/bitmath.o:./include/private/bitmath.h:46: first defined here .libs/fixed.o:

for am in automake-$AM_NEEDED automake$AM_NEEDED \ automake automake-1.7 automake-1.8 automake-1.9 automake-1.10; do This code makes it check for automake-1.7 (AM_NEEDED evaluates to 1.7), then automake (unversioned wrapper), then 1.7 (again), 1.8, 1.9 and then 1.10 1) Why the check is generally ascending? Isn't it better use the most recent version that is known to work instead of

There is a function FLAC__clz_soft_uint32 in bitmath.h: static inline unsigned int FLAC__clz_soft_uint32(unsigned int word) { static const unsigned char byte_to_unary_table[] = { 8, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, .................................... 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }; return (word) > 0xffffff ?

Hello, Upon compiling the flac tree today, after many successful compilations over the last few weeks, a new error is appearing before compilation bails out. This is a cross-compilation using gcc-5.3.0 running on GNU/Linux, with the objects being built for a mingw-w64-x86_64 host. Among other things, the compiler is looking for windows_unicode_filenames.h but it isn't there. Also, I'm

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:

Not sure where bug reports are going yet. I'd love to try to cross-compile with mingw, but git fails to build out of the box so far; these scripts work for most any other git tree I've used them on before. All that's done: ./autogen.sh ./configure --prefix=/home/avuton/src/mpd-release-utils/build-dir --host=i586-mingw32msvc - -build=x86_64-linux-gnu --target=i586-mingw32msvc

On Wed, May 23, 2001 at 03:18:16PM -0700, Josh Coalson wrote: > but since I'm not too saavy with autoconf/automake I'll ask for a little bit > more help. I think the only non-functional part left is that automake > doesn't support source files that are in subdirectories, relative to > Makefile.am(?) the layout in src/libFLAC/ is that all asm sources will go > under a

Hi, I was wondering how much worse FLAC performance would be if it was compiled integer-only, but while trying to do so (by adding #define FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got this error > ./include/private/bitmath.h:134:5: error: operator '&&' has no left > operand bitmath.h:134 is the following line > #if &&

Hello everybody! I have a list of length 5000 whose components are (mostly) "ts" objects, but some these components are intentionally left empty, ie, they are "NULL" components of the list. My question is how can I get the position of these null components in a effective way (I'm trying to avoid a for-if rutine). Thanks!!! [[alternative HTML version deleted]]

Dear R-folks: I have a group of data ('x' and 'y' axis), but I'd like to know how to draw a graph which would fits my data in a better way, I also need its equation. Could you give me any R-rutine ideas?. I thank you in advance for your kind support. [[alternative HTML version deleted]]

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory