similar to: Failed win32 build

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

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

Latest git [3b41451197f2cc7afb13753caaccbadaa74eca32] cross compiles perfect without patches (this is the first time I've seen this with any flac tree). Install fails with --disable-doxygen-docs; it's probably easy to fix, but here's the problem: make[5]: Entering directory `/home/avuton/src/mpd-release-utils/src/flac.git/doc/html/images/hw' make[5]: Nothing to be done for

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 ?

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

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

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

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 -

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

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

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

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure

I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) and either canonicalize NaNs or don’t support denormals. This is actually important because this kind of bitmath on floats is very commonly used as part of algorithms for complex math functions that need to get

It’s definitely one that would need some target hooks, and is probably not actually worth doing without analysing the producers and consumers of the value. If the source and destination values need to be in floating point registers, the cost of FPR<->GPR moves is likely to be a lot higher than the cost of the subtract, even if the xor is free. If the results are going to end up in integer

Hi, I am looking for a way to stream live audio using the FLAC audio format. After some analysis myself I found various lossy alternatives, also in higher levels of kbps (like MP3 320 kbps). But I do want to challenge and be sure whether FLAC might be a possibility. So I am specifically looking for an encoder and server solution supporting live streaming FLAC audio. Do you have a

On 25.5.2013 10:54, Erik de Castro Lopo wrote: > Robert Kausch wrote: > >> 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: >>

FLAC code usually uses tabs. However there are several places where spaces are used. The patch spaces_1.patch fixes several files, spaces_2.patch fixes solely libFLAC/include/private/bitmath.h (too many changed lines, so I made it separate). -------------- next part -------------- A non-text attachment was scrubbed... Name: spaces_1.patch Type: application/octet-stream Size: 5942 bytes Desc: not

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Well first of all, none of them apply :-). I'll try to redo the necessary patches with git. > * Remove restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and

lvqcl wrote: > Also MSVC fails because src/libFLAC/include/private/bitmath.h now > contains "uint32_t long idx" instead of "unsigned long idx". Ah, missed that because it was MSVC code. They should be `uint64_t`. > According to MSDN _BitScanReverse*() functions have signatures: > unsigned char _BitScanReverse(unsigned long *, unsigned long); > unsigned char

I found a bug near your backtrace, whenever sizeof(size_t)==32. I checked in a fix, can you try it now? Jos --- Josh Coalson <xflac@yahoo.com> wrote: > ok, thanks for the details, I'll take a look. > > Josh > > --- Avuton Olrich <avuton@gmail.com> wrote: > > > On 6/4/06, Avuton Olrich <avuton@gmail.com> wrote: > > ...more stuff... >