similar to: Pre-release 1.3.0pre4 (hopefully the last)

Compiling on OS X 10.8 x86_64 as we speak. On Sun, Apr 28, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body

I successfully compiled 1.3.0pre4 on MacOS X 10.8 and the tests succeeded. My configuration is Configuration summary : FLAC version : ........................ 1.3.0pre4 Host CPU : ............................ x86_64 Host Vendor : ......................... apple Host OS : ............................. darwin12.3.0 Compiler is GCC : ..................... yes GCC

On 28-04-13 13:23, LRN wrote: > On 28.04.2013 13:38, Erik de Castro Lopo wrote: >> I have tagged 1.3.0pre4 in git and provided a tarball here: >> >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz >> >> I have built and tested the git tree on: >> >> linux-x86_64 openbsd5-i386 freebsd5-i386 > i686-w64-mingw32 - builds correctly,

On 04/28/13 02:38 am, Erik de Castro Lopo wrote: > Hi all, > > I have tagged 1.3.0pre4 in git and provided a tarball here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz On OS/2 compile dies here, CC win_utf8_io/win_utf8_io.lo win_utf8_io/win_utf8_io.c:13:75: error: windows.h: No such file or directory ... with lots of more errors. The problem is

Hi everyone, I'm trying to get started with libFLAC++. I've built the static libs libFLAC, libFLAC++ and libogg using VS2010 on windows 7. However when I try build the example project "example_cpp_encode_file" I get a lot of linker errors. I checked linker/input/additional dependencies and added the paths for libFLAC, libFLAC++ and corrected the path for libogg. Now I'm just

Hi all, The latest pre-release is here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz but there will probably need to be at least one more. I've tested this on x86_64-linux powerpc-linux i386-openbsd5.2 i386-freebsd9 The majority of changes since the last pre-release is the addition of Janne Hyv?rinen's utf8 I/O functionality. Janne's

Hi, I tested my own Win32 compile of pre1 and pre2 one or two weeks ago (flac.exe through foobar2000 for transcoding), and the results were as expected: no errors, roughly same speed on my Intel Core i...something mobile, very slightly improved compression performance in comparison with 1.3.1). I didn't test all -1..-8 modes, but I diffed the source code of libFLAC between 1.3.1 and 1.3.2,

A bug was reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739613 get_console_width() may return 0, and there will be division by 0 in stats_print_name(): console_width = get_console_width(); len = strlen_console(name)+2; console_chars_left = console_width - (len % console_width); A simple patch is attached. -------------- next part -------------- A non-text attachment was

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple

Hi! I've installed FreeBSD5 (i386). I've synced src tree via cvsup (RELENG_5) and tried to build world. But in the process I got the following error: /usr/src/secure/lib/libcrypto/i386/des-586.s:2363:33: warning: null character(s) ignored {standard input}:2367: Error: invalid character '=' in operand 1 *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes

Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) > CCLD utf8/libutf8.la > CC win_utf8_io/win_utf8_io.lo > win_utf8__io/win_utf8_io.c:266:13: error: static declaration > of 'set_filename_utf8' follows

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

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

Janne Hyv?rinen wrote: > Win_utf8 stuff should not be included in libflac since it's only to be > used by the flac.exe frontend. It is not needed by other programs nor > would they benefit from it without doing the extra work of converting > their ansi filenames and functions to utf-8. > >> Version 2 of my patch attached, which fixes the problem for the >>

Currently it is required to include share/compat.h before inclusion of share/win_utf8_io.h. That's because of print_console() declaration: its 3rd argument have type 'uint32_t' which is defined in share/compat.h. So share/win_utf8_io.h depends on share/compat.h which in turn includes share/win_utf8_io.h. Not a problem but it's a bit ugly imho. Actually, the 3rd argument of

Well, I'm bored, and I hope I'm not getting in the way of anyone, but I was like hell might as well try to make a new Xcode project, although I am using 10.8 with the latest xcode, so I'd have to manually remove that, but there is one serious concern, and that's that header files are being called from 1 directory up from where they are, for example: "share/compat.h"

Felix Homann wrote: > Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3: It seems Android sys/param.h doesn't define MIN/MAX. Could you try to revert this commit on current master (or simply change line 35 of src/libFLAC/include/private/macros.h back to #if defined(__GNUC__) ) and recompile? Or possibly bisect 03a9e60..master to find out when the

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add