Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 06:09:06PM +0200, Miroslav Lichvar wrote: On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Will be this patch included in the upcoming release? Or does it need more work before it can be accepted? -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote: El 03/05/12 12:19, Miroslav Lichvar escribió: It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous. It seems the current compilers are not that good yet :). In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Git branch with compiling fixes for win32
On May 7, 2012, at 06:11, Miroslav Lichvar wrote: On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote: El 03/05/12 12:19, Miroslav Lichvar escribió: It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous. It seems the current compilers are not that good yet :). In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. Thank you for running these benchmarks and reporting on the results, Miroslav. As a sometimes assembly coder, I believe that compilers will never be able to beat a human mind in all situations, even if they can in most. I can't speak for the FLAC assembly developers, but when I write assembly, I always check the compiler's output at all optimization settings just to be sure I'm not wasting my time. That certainly doesn't guarantee that the compiler will never improve its results, but keep in mind that changes to compilers sometimes produce less optimal results for particular cases, even if they involve improvements in most general cases. But it's certainly good to double-check periodically as compilers improve. Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote: In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. Was that with -O2 or -O3? Not sure, I didn't set CFLAGS which seems to result in using both: -O3 -funroll-loops -Wall -W -Winline -g -O2 I think funroll-loops can be harmful, the Fedora package is compiled with -O2 and funroll-loops is used only for the stream_encoder file and it seems decoding is a tiny bit faster than with the git version. Unfortunately I don't recall the details. On Mon, May 07, 2012 at 01:23:03PM -0400, Cristian Rodríguez wrote: Did you build with -fprofile-generate ... then make check .. then rebuild with -fprofile-use ? No, I have not tried that. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 07/05/12 13:37, Miroslav Lichvar escribió: On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote: In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with nasm enabled is about 7% faster in decoding than without nasm. x86_64 build is about 2% faster than the i686 build with nasm enabled. Was that with -O2 or -O3? Not sure, I didn't set CFLAGS which seems to result in using both: -O3 -funroll-loops -Wall -W -Winline -g -O2 I think funroll-loops can be harmful, the Fedora package is compiled with -O2 and funroll-loops is used only for the stream_encoder file and it seems decoding is a tiny bit faster than with the git version. Unfortunately I don't recall the details. On Mon, May 07, 2012 at 01:23:03PM -0400, Cristian Rodríguez wrote: Did you build with -fprofile-generate ... then make check .. then rebuild with -fprofile-use ? No, I have not tried that. Yes, -funroll-loops might cause code growth and/or make binaries actually slower... BTW, just wondering, how are you measuring the speed in this tests ? I would be interested to know so I can reproduce it here with different compile/link options ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
From: Miroslav Lichvar mlich...@redhat.com Sent: Friday, May 4, 2012 9:09 AM On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Excellent! ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 03/05/12 12:19, Miroslav Lichvar escribió: Hi Josh, nice to see you here again. On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: (Jumping in again, maybe at the wrong point since this doesn't seem to involve encoding, but here goes.) Miroslav's patches have always been high-quality for sure. But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. If there were ever a libFLAC release that had a bug and was not always lossless, that would be very damaging to the format. The bitreader patch touches only the rice decoding code which I believe is very well covered by the test suite and any bugs would be quickly seen. Also, it has also been included in the Fedora packages for several years, no bug reports about MD5 mismatch were received yet :). It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. I'm not sure if anyone is planning to port the asm code to x86_64, I think that it will be quite a lot of work, perhaps it would be a good time to reconsider using inline assembly instead of nasm to minimize the amount of asm code? It would be useful to know how much are the individual asm routines actually faster, it has been a long time since I played with it. Hi: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. Cheers! ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 03/05/12 12:19, Miroslav Lichvar escribió: It makes the C function faster than the corresponding asm routine, so if it's included I'd suggest to just drop the asm function to not keep around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. BTW, how much faster is the code with the clz builtin? If the architecture doesn't have the instruction, will be the gcc code as fast as the original code? -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 04/05/12 11:53, Miroslav Lichvar escribió: On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote: Both Erick and I did already submitted patches to the tree that do just exactly what your flac-1.2.1-bitreader.patch intended.. please checkout current GIT tree. The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Ah ok, I will check it out ! BTW, how much faster is the code with the clz builtin? If the architecture doesn't have the instruction, will be the gcc code as fast as the original code? I do not have access to a host that does not have either bsr, clz, lzcnt, cntlz or ctlz. if you do, plz share your results ;) I have no idea what code will be generated in exotic archs, in x86 it translates to bsr ^ 31U and in the others supported to a single instruction. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
El 04/05/12 12:09, Miroslav Lichvar escribió: On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: The most interesting part of the patch is the rewrite of the FLAC__bitreader_read_rice_signed_block function, which in the git repo seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. Looking at the openSUSE trees, we carry this patch since Aug 2011 and have recieved no reports on it being broken, also it works fine in my machine ;) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Largest risks are: 1) encoding errors in a scenario not exercised by the tests 2) violations of the spec that are tolerated by the decoder. I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. On Apr 26, 2012, at 2:49 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. What exactly is the problem? New versions of the encoder producing files that can't be decoded by older decoders or something else? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 12-04-25 5:11 PM, Josh Coalson wrote: Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Coverage of the test suite is something the test suite could be extended to measure. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. Sadly, this remains true anyway. It's best to have both automatic and human checks. Both are fallible. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Op 26-04-12 10:27, Ben Allison schreef: I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. So, would it be useful to include some of tests run by another (or several other) decoder(s)? Probably an older FLAC release of some 3rd party decoder, I guess there are quite some implementations. Yes, that's even more dependencies and once more increasing the test suite run length. However, as said earlier, a release with an encoder error is probably the worst thing that can happen to FLAC. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. What exactly is the problem? New versions of the encoder producing files that can't be decoded by older decoders or something else? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/3/2012 06:33, JonY wrote: On 2/3/2012 02:50, Erik de Castro Lopo wrote: JonY wrote: Attached patch builds without any warnings for MinGW. Sorry JonY, that patch does not apply against current git master which is here: https://git.xiph.org/?p=flac.git;a=summary Specifically I pulled out much of the #ifdef _MSC_VER printf stuff in this commit: https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 For example (damn thats a horrible URL): https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b Since your patch seems pretty similar to what I have already commited, I wouldn't be surprised it what we have now doesn't just compile correctly under MinGW. OK, will redo patch later today. My git repo still pointed to the old /mirrors/flac.git link, so I didn't get any updates. OK, rebuilt with latest master, no more printf warnings. Here's another attached patch to suppress redefinition warnings with mingw-w64 lfs64 support. diff --git a/src/flac/decode.c b/src/flac/decode.c index 05d86f3..2173669 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -29,10 +29,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include errno.h #include math.h /* for floor() */ #include stdio.h /* for FILE etc. */ diff --git a/src/flac/encode.c b/src/flac/encode.c index dafa105..87ef2ef 100644 --- a/src/flac/encode.c +++ b/src/flac/encode.c @@ -29,10 +29,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include errno.h #include limits.h /* for LONG_MAX */ #include math.h /* for floor() */ diff --git a/src/flac/foreign_metadata.c b/src/flac/foreign_metadata.c index 7e273a5..d4fb7c2 100644 --- a/src/flac/foreign_metadata.c +++ b/src/flac/foreign_metadata.c @@ -23,10 +23,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include stdio.h /* for FILE etc. */ #include stdlib.h /* for calloc() etc. */ #include string.h /* for memcmp() etc. */ diff --git a/src/flac/iffscan.c b/src/flac/iffscan.c index da74a5f..2cb9075 100644 --- a/src/flac/iffscan.c +++ b/src/flac/iffscan.c @@ -26,10 +26,14 @@ #if defined _MSC_VER || defined __MINGW32__ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include foreign_metadata.h static FLAC__uint32 unpack32be_(const FLAC__byte *b) diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index ac6473e..9ef9882 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -47,9 +47,13 @@ #include io.h /* for chmod() */ #include sys/types.h /* for off_t */ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif +#endif #else #include sys/types.h /* some flavors of BSD (like OS X) require this to get time_t */ #include utime.h /* for utime() */ diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index 72d9e43..0323d73 100644 --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@ -48,10 +48,14 @@ #include sys/types.h /* for off_t */ #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include FLAC/assert.h #include share/alloc.h #include protected/stream_decoder.h diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index 8fb3209..0b6d8c2 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -48,10 +48,14 @@ #include sys/types.h /* for off_t */ #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__ #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ +#ifndef fseeko #define fseeko fseek +#endif +#ifndef ftello #define ftello ftell #endif #endif +#endif #include FLAC/assert.h #include FLAC/stream_decoder.h #include share/alloc.h diff --git a/src/test_libFLAC/decoders.c b/src/test_libFLAC/decoders.c index e45e722..70127cf 100644 --- a/src/test_libFLAC/decoders.c +++
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/1/2012 22:36, JonY wrote:
On 2/1/2012 18:52, Erik de Castro Lopo wrote:
JonY wrote:
Alright, here's a quick fix, although it is more ugly than I remembered.
Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
where available, and falls back to I64 on MSVC and then ll for others,
all format warnings suppressed.
JonY,
Sorry for the delay on actually getting on to this.
I tried your patch, but it wasn't quite right. The problem is that %ll
is the correct format specifier for uint64_t on 32bit Linux but not
on 64 bit Linux.
Something is very very wrong about the above statements. I thought I
used PRI?64 when inttypes.h is found (Linux should have it, old code
uses %ll? anyway for non-msvc, so shouldn't have any new issues).
inttypes.h and stdint.h is supposed to be abstractions to remove these
issues.
In C99, the correct way to print a uint64_t value is:
printf (THe value is : PRIu64 \n, value) ;
I have gone ahead and fixed this through the code and fixed this, but I
may have broken some either MSVC or MinGW on the way. I'd appreciate it
if you test whats in git now.
For those files where any compiler baulks at the PRIu64/PRIx64/PRId64,
you should add a #ifdef block that might look something like:
#ifdef HAVE_INTTYPES_H
#include inttypes.h
#else
#if defined (_MSC_VER) ! defined (PRId64)
#define PRId64 I64d
#endif
#if defined (_MSC_VER) ! defined (PRIu64)
#define PRIu64 I64u
#endif
#endif
We'll worry about compilers that don't have the PRI_64 values as we find
them.
OK, I'll do a quick test build tomorrow. More thorough testing will come
during the weekends.
Attached patch builds without any warnings for MinGW.
diff --git a/examples/c/decode/file/main.c b/examples/c/decode/file/main.c
index 32b5559..67028bb 100644
--- a/examples/c/decode/file/main.c
+++ b/examples/c/decode/file/main.c
@@ -31,6 +31,7 @@
#include stdio.h
#include stdlib.h
#include FLAC/stream_decoder.h
+#include FLAC/compat.h
static FLAC__StreamDecoderWriteStatus write_callback(const FLAC__StreamDecoder
*decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void
*client_data);
static void metadata_callback(const FLAC__StreamDecoder *decoder, const
FLAC__StreamMetadata *metadata, void *client_data);
@@ -174,11 +175,7 @@ void metadata_callback(const FLAC__StreamDecoder *decoder,
const FLAC__StreamMet
fprintf(stderr, sample rate: %u Hz\n, sample_rate);
fprintf(stderr, channels : %u\n, channels);
fprintf(stderr, bits per sample: %u\n, bps);
-#ifdef _MSC_VER
- fprintf(stderr, total samples : %I64u\n, total_samples);
-#else
- fprintf(stderr, total samples : %llu\n, total_samples);
-#endif
+ fprintf(stderr, total samples : %PRIu64\n, total_samples);
}
}
diff --git a/examples/c/encode/file/main.c b/examples/c/encode/file/main.c
index 0f7f4c0..9be55b0 100644
--- a/examples/c/encode/file/main.c
+++ b/examples/c/encode/file/main.c
@@ -33,6 +33,7 @@
#include string.h
#include FLAC/metadata.h
#include FLAC/stream_encoder.h
+#include FLAC/compat.h
static void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned
total_frames_estimate, void *client_data);
@@ -164,10 +165,5 @@ int main(int argc, char *argv[])
void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned
total_frames_estimate, void *client_data)
{
(void)encoder, (void)client_data;
-
-#ifdef _MSC_VER
- fprintf(stderr, wrote %I64u bytes, %I64u/%u samples, %u/%u frames\n,
bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
-#else
- fprintf(stderr, wrote %llu bytes, %llu/%u samples, %u/%u frames\n,
bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
-#endif
+ fprintf(stderr, wrote %PRIu64 bytes, %PRIu64/%u samples, %u/%u
frames\n, bytes_written, samples_written, total_samples, frames_written,
total_frames_estimate);
}
diff --git a/include/FLAC/compat.h b/include/FLAC/compat.h
new file mode 100755
index 000..831d882
--- /dev/null
+++ b/include/FLAC/compat.h
@@ -0,0 +1,57 @@
+/* libFLAC - Free Lossless Audio Codec library
+ * Copyright (C) 2001,2002,2003,2004,2005,2006,2007,2008,2009 Josh Coalson
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. JonY, Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. In C99, the correct way to print a uint64_t value is: printf (THe value is : PRIu64 \n, value) ; I have gone ahead and fixed this through the code and fixed this, but I may have broken some either MSVC or MinGW on the way. I'd appreciate it if you test whats in git now. For those files where any compiler baulks at the PRIu64/PRIx64/PRId64, you should add a #ifdef block that might look something like: #ifdef HAVE_INTTYPES_H #include inttypes.h #else #if defined (_MSC_VER) ! defined (PRId64) #define PRId64 I64d #endif #if defined (_MSC_VER) ! defined (PRIu64) #define PRIu64 I64u #endif #endif We'll worry about compilers that don't have the PRI_64 values as we find them. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Bastiaan Timmer wrote: Well, I have been away a couple of days, so I don't know if I'm in time, but I reported a memory leak and submitted a patch a couple of months ago. It would be nice if it can make it in. I first reported the leak here: http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html And the patch is here: http://sourceforge.net/tracker/?func=detailaid=3390048group_id=13478atid=313478 I've applied that patch. Thanks. I'll be working my way through the rest on SF.net in next week or two. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
LRN wrote: Is it wise to aim at C99? While i have absolutely nothing against it, it is a known fact that MS never got around to support C99 in MSVC to any considerable degree. The idea is to only use the bits of C99 that can be worked around in MSVC with #ifdefs and #defines. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 2/1/2012 18:52, Erik de Castro Lopo wrote: JonY wrote: Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. JonY, Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. Something is very very wrong about the above statements. I thought I used PRI?64 when inttypes.h is found (Linux should have it, old code uses %ll? anyway for non-msvc, so shouldn't have any new issues). inttypes.h and stdint.h is supposed to be abstractions to remove these issues. In C99, the correct way to print a uint64_t value is: printf (THe value is : PRIu64 \n, value) ; I have gone ahead and fixed this through the code and fixed this, but I may have broken some either MSVC or MinGW on the way. I'd appreciate it if you test whats in git now. For those files where any compiler baulks at the PRIu64/PRIx64/PRId64, you should add a #ifdef block that might look something like: #ifdef HAVE_INTTYPES_H #include inttypes.h #else #if defined (_MSC_VER) ! defined (PRId64) #define PRId64 I64d #endif #if defined (_MSC_VER) ! defined (PRIu64) #define PRIu64 I64u #endif #endif We'll worry about compilers that don't have the PRI_64 values as we find them. OK, I'll do a quick test build tomorrow. More thorough testing will come during the weekends. signature.asc Description: OpenPGP digital signature ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: Sorry for the delay on actually getting on to this. I tried your patch, but it wasn't quite right. The problem is that %ll is the correct format specifier for uint64_t on 32bit Linux but not on 64 bit Linux. Something is very very wrong about the above statements. I thought I used PRI?64 when inttypes.h is found (Linux should have it, old code uses %ll? anyway for non-msvc, so shouldn't have any new issues). I think that may have been because configure was not detecting inttypes.h when I first tested that patch. inttypes.h and stdint.h is supposed to be abstractions to remove these issues. For the inttypes.h and stdint.h problem the way I usually prefer to tackle it is: a) Assume they are there. b) When they aren't, add the required #ifdef/#define nonsense to define them for the compiler when they are missing. OK, I'll do a quick test build tomorrow. More thorough testing will come during the weekends. Cool, thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
On 12/06/2011 08:44 AM, Erik de Castro Lopo wrote: Sven-Hendrik Haase wrote: Sooo any news? Unfortunately, my day job, my family and a bunch of other commitments have been getting in my way. I *know* I will have some free time between xmas and new year. I have no guarantees of any decent block of time showing up before that. Erik Poke ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 07:47 PM, Erik de Castro Lopo wrote: Avuton Olrich wrote: Hello, Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. There is a Git branch on the Xiph server here: http://git.xiph.org/?p=flac.git;a=summary When I find a little bit of time (the weekend) I will be validating these patches and commiting them to that repo. Erik Sooo any news? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Sven-Hendrik Haase wrote: Sooo any news? Unfortunately, my day job, my family and a bunch of other commitments have been getting in my way. I *know* I will have some free time between xmas and new year. I have no guarantees of any decent block of time showing up before that. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 06:49, JonY wrote: On 11/16/2011 03:20, Erik de Castro Lopo wrote: JonY wrote: On 11/14/2011 18:01, JonY wrote: On 11/10/2011 19:22, JonY wrote: On 11/10/2011 18:39, Erik de Castro Lopo wrote: I'm subscribed to the list (and I set my reply-to to the list). Please do not CC me. JonY wrote: Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. I'm a Linux guy. I do not have easy access to a windows machine and don't have the time or patience to maintain one. For windows stuff I'll be relying on others to provide and test patches. Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. Ifdef changes now consolidated into a single file. Ping, no comments? I noticed some more ifdeferies around that needs consolidating and warnings that need suppressing, that can go into a separate patch. Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying to make my machine usable. Erik Wow ok, haven't touched it since the gnone2 days, it was pretty decent back then. I'll come back later then. Ping, anything new? signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: Wow ok, haven't touched it since the gnone2 days, it was pretty decent back then. I'll come back later then. Ping, anything new? Well I've replaced Gnome3 with XMonad which is a huse step in the right direction. Still super busy with a bunch of other things (eg family, the day job and looking for a new day job :-) ). I do expect to get around to this. Just having a bit of trouble having a nice clean 6-8 hour block which I can devote to this. If anyone else has free time, I'd have no problem with them jumping in and helping. Just please co-ordinate here. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: This will leave Apple with even less reasons to support FLAC ... You make some important observations, but I do not see how anything can be done by the FLAC team about Apple's lack of support. I think that only people who work for Apple can do anything to persuade Apple to (ahem) think different about FLAC. I'm guessing there is a strong Not Invented Here effect at work. As for FLAC, no news is good news. That means the code is stable and bug free. I appreciate that, a lot. That's why I run mostly Debian or Ubuntu LTS on machines that need to be stable (but don't need to have the latest fancy stuff). Unfortunately, most people tend to prefer the latest fancy stuff (in devices and installed software) so for those people lack of change is usually seen as a bad thing. Although having said that, last time I had to install FLAC on a Windows PC (someone else's) the GUI front-end that I downloaded came with an older flac.exe than the current FLAC version at the time. It seems that all of the recent updates have been efforts to port FLAC to operating systems like Windows and Linux. In terms of your comments above, Windows/Linux support does absolutely nothing to help FLAC compete against ALAC on the OSX platform. Not directly, no... ...but most people like New Stuff as opposed to not fixing something that isn't broken. Enough to cause more interest in Apple Lossless as a supported format (outside of Apple devices) and therefore less interest in FLAC. It could even cause some music download sites to reconsider their support of FLAC. It is indeed noteworthy that Apple has released the source for ALAC. The power of FLAC is that it was designed for embedded systems from the beginning, and that's why you see portable recorders like the Sound Devices 700 Series supporting FLAC, as well as various optical disc players (CD, DVD, etc.). One question that remains for me is whether Apple's ALAC open source can be ported to these kinds of embedded systems with the same ease. I wish I could afford a portable recorder from Sound Devices! They record multichannel or stereo in FLAC aswell as playing it, right? Obviously, FLAC requires much less horsepower to decode than to encode, and that's OK (for most uses) because the decode will happen more often. I can live with uncompressed recording, but when buying hardware, FLAC support is always a deciding factor. However, almost every device that can play audio (from el-cheapo DVD players, to almost every pro DJ or broadcast deck) is able to play MP3 files. Most of them can also play WMA and AAC (lossy), but FLAC support on mass-market devices is rare. There is such a huge variety of chipsets and other hardware elements that it's impractical to port Rockbox to them. For example, OPPO do some very nice DVD and BD players for the home theatre and audiophile markets. But only their top-range players can play FLAC files. That is according to their own website, but it may be a hidden extra. Similarly, CD DJ decks from Pioneer and Denon seem to support every lossy compressed audio format, but not lossless. And to make it even worse, Silvio Zeppieri (Denon brand manager) commented on www.denondjforums.com (in Feb 2010) that their reason for not supporting FLAC was that hard drives are cheap now, so just use WAV for lossless instead, as it would cost Denon too much to develop FLAC support. FolderPlay (app for Nokia S60) is what I listen to music with on the move every day (mostly FLAC, some MP3) and the developer told me that it took him half a day to add FLAC support. Whereas Denon were afraid that the DJ features (scratch, loop in/out points, etc) that are already possible on Denon hardware in WAV, will cost them too much development time to support in FLAC. What impressed me most about the discussion on www.denondjforums.com wasn't the overall defeatist attitude from a Denon manager (he said no direct FLAC sales in Feb 2010), but that most of the other people on the forum agreed that hard drives are so cheap that lossless has no real advantage: digital DJs should either use MP3s (not caring about sound quality) or WAV (not caring about storage space). And now we find ourselves in a world where hard drives are suddenly not cheap anymore... -- -Dec. --- Mosaic is going to be on every computer in the world. - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Well the memory leak I mentioned in my previous message for one. But there are plenty more listed here: http://sourceforge.net/tracker/?atid=113478group_id=13478func=browse and here: http://sourceforge.net/tracker/?atid=313478group_id=13478func=browse Admittedly I haven't read all of those, maybe some are invalid or actually feature requests, but surely some more actual, valid bugs are listed there as well. So I would be happy if (after 2 years) someone would take care of a couple of open reports. At least those where users have already submitted patches to fix them (after reviewing the patch of course). --- On Sat, 11/19/11, Brian Willoughby bri...@sounds.wa.com wrote: From: Brian Willoughby bri...@sounds.wa.com Subject: Re: [Flac-dev] Git branch with compiling fixes for win32 To: Bastiaan Timmer basjetim...@yahoo.com Cc: flac-dev@xiph.org Date: Saturday, November 19, 2011, 4:48 AM What bugs? On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Well, I have been away a couple of days, so I don't know if I'm in time, but I reported a memory leak and submitted a patch a couple of months ago. It would be nice if it can make it in. I first reported the leak here: http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html And the patch is here: http://sourceforge.net/tracker/?func=detailaid=3390048group_id=13478atid=313478 And there are plenty more patches on the sourceforge tracker if you want to apply more. (But I obviously haven't checked them all and what they are supposed to fix.) It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? thanks, Bas Timmer --- On Wed, 11/9/11, Erik de Castro Lopo mle...@mega-nerd.com wrote: From: Erik de Castro Lopo mle...@mega-nerd.com Subject: Re: [Flac-dev] Git branch with compiling fixes for win32 To: flac-dev@xiph.org Date: Wednesday, November 9, 2011, 10:58 PM Sven-Hendrik Haase wrote: Si señor: http://code.entropywave.com/git/flac.git Ok, there are about 6 commits there. Over the weekend I'll have a look at them and if they're fine, I'll push them to the Xiph Git repo. If anyone else has Flac patches that they would like to see commited to the Xiph Git repo, now would be a good time to speak up. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
What bugs? On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Hello, Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. -- avuton -- If someone nearby has an iphone and leaves it near you, be aware they may be spying on you. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Avuton Olrich wrote: Hello, Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. There is a Git branch on the Xiph server here: http://git.xiph.org/?p=flac.git;a=summary When I find a little bit of time (the weekend) I will be validating these patches and commiting them to that repo. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote: Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. Looking at the FLAC website, the most recent news is almost 2 years old, and there's no evidence to show that the project's still live. I haven't seen any post from Josh Coalson on this list in a while: is he still running the project? Something else to think about: Apple recently released sources for Apple Lossless reference utilities. It's all under an Apache license. This will (presumably) lead to more software developers spending more time improving ALAC support in their projects, with more reference material available than the unofficial reverse-engineered code (as used in vlc and libavcodec). This will leave Apple with even less reasons to support FLAC in their own products. Anyone with an iPad/iPhone/iPod must install Rockbox to play FLAC files, and the Apple TV can only play FLAC (and anything that was not bought from iTunes) using XBMC, after being jailbroken. But for the Average End User, they don't want to have to jump through a bunch of hoops to get FLAC support. Apple Lossless will Just Work on all Apple devices (as it always did), but now it's more freely available so the freedom-loving hippies can stop complaining about the source code. -- -Dec. --- Mosaic is going to be on every computer in the world. - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Nov 16, 2011, at 14:11, Declan Kelly wrote: On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote: Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. Looking at the FLAC website, the most recent news is almost 2 years old, and there's no evidence to show that the project's still live. I haven't seen any post from Josh Coalson on this list in a while: is he still running the project? Something else to think about: Apple recently released sources for Apple Lossless reference utilities. It's all under an Apache license. This will (presumably) lead to more software developers spending more time improving ALAC support in their projects, with more reference material available than the unofficial reverse-engineered code (as used in vlc and libavcodec). This will leave Apple with even less reasons to support FLAC in their own products. Anyone with an iPad/iPhone/iPod must install Rockbox to play FLAC files, and the Apple TV can only play FLAC (and anything that was not bought from iTunes) using XBMC, after being jailbroken. But for the Average End User, they don't want to have to jump through a bunch of hoops to get FLAC support. Apple Lossless will Just Work on all Apple devices (as it always did), but now it's more freely available so the freedom-loving hippies can stop complaining about the source code. Declan, You make some important observations, but I do not see how anything can be done by the FLAC team about Apple's lack of support. As for FLAC, no news is good news. That means the code is stable and bug free. As a seasoned software developer, I've learned the hard way that every single change to a source code repository is a chance for a new or old bug to appear. I am not aware of any bugs in FLAC, so the lack of changes is perfect. It seems that all of the recent updates have been efforts to port FLAC to operating systems like Windows and Linux. In terms of your comments above, Windows/Linux support does absolutely nothing to help FLAC compete against ALAC on the OSX platform. It is indeed noteworthy that Apple has released the source for ALAC. The power of FLAC is that it was designed for embedded systems from the beginning, and that's why you see portable recorders like the Sound Devices 700 Series supporting FLAC, as well as various optical disc players (CD, DVD, etc.). One question that remains for me is whether Apple's ALAC open source can be ported to these kinds of embedded systems with the same ease. Yes, it has always been an issue that Apple never seemed motivated to support FLAC as a first class file format in OSX, CoreAudio, iTunes, and their hardware platforms based on iOS. I really don't see how there is much that Josh Coalson or anyone outside Apple can do about this. If people in the FLAC community have CoreAudio converters for FLAC or iTunes plugins for FLAC, then it would be great to see those contributed to the open source collection. However, none of those items would really result in a change to the FLAC library sources, which have been stable and solid for a respectable amount of time. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/14/2011 18:01, JonY wrote: On 11/10/2011 19:22, JonY wrote: On 11/10/2011 18:39, Erik de Castro Lopo wrote: I'm subscribed to the list (and I set my reply-to to the list). Please do not CC me. JonY wrote: Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. I'm a Linux guy. I do not have easy access to a windows machine and don't have the time or patience to maintain one. For windows stuff I'll be relying on others to provide and test patches. Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. Ifdef changes now consolidated into a single file. Ping, no comments? I noticed some more ifdeferies around that needs consolidating and warnings that need suppressing, that can go into a separate patch. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: On 11/14/2011 18:01, JonY wrote: On 11/10/2011 19:22, JonY wrote: On 11/10/2011 18:39, Erik de Castro Lopo wrote: I'm subscribed to the list (and I set my reply-to to the list). Please do not CC me. JonY wrote: Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. I'm a Linux guy. I do not have easy access to a windows machine and don't have the time or patience to maintain one. For windows stuff I'll be relying on others to provide and test patches. Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. Ifdef changes now consolidated into a single file. Ping, no comments? I noticed some more ifdeferies around that needs consolidating and warnings that need suppressing, that can go into a separate patch. Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying to make my machine usable. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 03:20, Erik de Castro Lopo wrote: JonY wrote: On 11/14/2011 18:01, JonY wrote: On 11/10/2011 19:22, JonY wrote: On 11/10/2011 18:39, Erik de Castro Lopo wrote: I'm subscribed to the list (and I set my reply-to to the list). Please do not CC me. JonY wrote: Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. I'm a Linux guy. I do not have easy access to a windows machine and don't have the time or patience to maintain one. For windows stuff I'll be relying on others to provide and test patches. Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. Ifdef changes now consolidated into a single file. Ping, no comments? I noticed some more ifdeferies around that needs consolidating and warnings that need suppressing, that can go into a separate patch. Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying to make my machine usable. Erik Wow ok, haven't touched it since the gnone2 days, it was pretty decent back then. I'll come back later then. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/09/11 02:58 pm, Erik de Castro Lopo wrote: If anyone else has Flac patches that they would like to see commited to the Xiph Git repo, now would be a good time to speak up. A couple of build system fixes for OS/2. Not very experienced with git so just attaching. Dave From e47dc34e2025cf0b700a8ff9ebbb7fac7e7999f1 Mon Sep 17 00:00:00 2001 From: Dave Yeo dave.r.yeo@gmail.com Date: Tue, 15 Nov 2011 20:37:16 -0800 Subject: [PATCH 1/2] GCC on OS/2 defaults to A.OUT so nasm should also generate A.OUT object files --- configure.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.in b/configure.in index c6497a0..516edea 100644 --- a/configure.in +++ b/configure.in @@ -93,6 +93,7 @@ case $host in i386-*-openbsd3.[[0-3]]) OBJ_FORMAT=aoutb ;; *-*-cygwin|*mingw*) OBJ_FORMAT=win32 ;; *-*-darwin*) OBJ_FORMAT=macho ;; + *os2*) OBJ_FORMAT=aout ;; *) OBJ_FORMAT=elf ;; esac AC_SUBST(OBJ_FORMAT) -- 1.7.2.3 From 99a10229202ece9fd0be41af387911c694038187 Mon Sep 17 00:00:00 2001 From: Dave Yeo dave.r.yeo@gmail.com Date: Tue, 15 Nov 2011 21:25:47 -0800 Subject: [PATCH 2/2] Libtool fix for OS/2 to create shared libs (DLL) Libtool dies with this error libtool: link: warning: undefined symbols not allowed in i386-pc-os2-emx shared libraries without being passed --no-undefined --- configure.in |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 516edea..efed8dc 100644 --- a/configure.in +++ b/configure.in @@ -100,11 +100,15 @@ AC_SUBST(OBJ_FORMAT) case $host in *-*-cygwin|*mingw*) - # define this variable for enabling strict exports with libtool; for now, it's only supported by Win32 + # define this variable for enabling strict exports with libtool LT_NO_UNDEFINED=-no-undefined # -lwsock32 only needed because of ntohl() usage, can get rid of after that's gone: MINGW_WINSOCK_LIBS=-lwsock32 ;; + *os2*) + # OS/2 also supports this variable and needs it to produce a DLL + LT_NO_UNDEFINED=-no-undefined + ;; *) LT_NO_UNDEFINED= MINGW_WINSOCK_LIBS= -- 1.7.2.3 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 08:02, Erik de Castro Lopo wrote: JonY wrote: I submitted a patch sometime ago to correct printf specifiers for win32 by using inttypes.h, but there were no response, so I thought flac development was dead. Development is probably complete. Maintenance should continue. Not sure where the patch went or if its still valid. If you sent it to this list, the mailing list archive should be here: http://lists.xiph.org/mailman/listinfo/flac-dev Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Not sure if the patches you already have address this, but here are some hacks I collected to try to get libFLAC to build on Windows for Mixxx: http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac I have never actually gotten it to build on x64 and right now just use OpenCodecs' distribution (also mentioned at that link) which has Visual Studio files that build fine for me. Sincerely, Sean M. Pappalardo D.J. Pegasus Mixxx Developer - Controller Specialist ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Development is probably complete. Maintenance should continue. Speaking of which, I plan on starting AMD64, ARMv5, and ARMv7 assembly routines in the next few weeks. I'll sync up with Erik on getting them integrated. -Ben Allison ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Erik de Castro Lopo mle...@mega-nerd.com wrote: Sven-Hendrik Haase wrote: I found this git repo that contains fixes for mingw32 compilation of flac: git://code.entropywave.com/git/flac.git Switch to the ew branch to see the fixes. I'd be glad if this went upstream as it'd make my job easier. Is there a gitweb interface to this? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev Si señor: http://code.entropywave.com/git/flac.git -- Sven-Hendrik ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 06:58, Erik de Castro Lopo wrote: Sven-Hendrik Haase wrote: Si señor: http://code.entropywave.com/git/flac.git Ok, there are about 6 commits there. Over the weekend I'll have a look at them and if they're fine, I'll push them to the Xiph Git repo. If anyone else has Flac patches that they would like to see commited to the Xiph Git repo, now would be a good time to speak up. Cheers, Erik I submitted a patch sometime ago to correct printf specifiers for win32 by using inttypes.h, but there were no response, so I thought flac development was dead. Not sure where the patch went or if its still valid. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Git branch with compiling fixes for win32
I found this git repo that contains fixes for mingw32 compilation of flac: git://code.entropywave.com/git/flac.git Switch to the ew branch to see the fixes. I'd be glad if this went upstream as it'd make my job easier. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
