similar to: Lets do a 1.3.2 release

On 01/24/16 12:29 PM, Erik de Castro Lopo wrote:> Dave Yeo wrote: > >> After this the build dies with, >> util.c: In function 'benchmark_function': >> util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use >> in this function) >> clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &start) ; >> >> Would using

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

On 01/08/16 02:56 AM, Erik de Castro Lopo wrote: > HI all, > > I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been > building regularly on their platforms of interest Seems that the default binutils on OS/2 is

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

lvqcl wrote: > Then IMHO all three build systems (configure && make, Makefile.lite > and MSVC) should be synchronized with each other +1 > TO ERIK: > > I have some patches, but they either modify MSVC .vcxproj files, > or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos. > So should they be applied? rejected? postponed until after flac 1.3.2? We

I''m continuing to investigate the usage of rdtsc in userspace and whether there are programs "out there" that use it "unsafely" that might randomly break under Xen if rdtsc is not emulated, e.g. across a migration. Some have argued that nobody should use rdtsc and any programs that use rdtsc directly are "fundamentally broken" so the default for rdtsc

lvqcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently

lvqcl wrote: > When I compile flac project with MSYS/MinGW-w64, I can see two files: > libFLAC.a and libFLAC-static.a. The only difference between them > is that libFLAC.a contains functions from win_utf8_io. > But 'make install' adds libFLAC.a into /local/lib, not libFLAC-static.a. Thank you for checking this. I've always had trouble with Autotools on Windows, even when

Dave Yeo wrote: > On 01/24/16 12:29 PM, Erik de Castro Lopo wrote:> Dave Yeo wrote: > > > >> After this the build dies with, > >> util.c: In function 'benchmark_function': > >> util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use > >> in this function) > >> clock_gettime (CLOCK_PROCESS_CPUTIME_ID,

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

lvqcl wrote: > IIRC libFLAC.a built with "./autogen.sh && ./configure && make" > contains all functions from win_utf8_io. So I think it's possible > to change some Makefile.lite or maybe build/*.mk files so that > there will be no need to add -lwin_utf8_io to -lFLAC. Version 2 of my patch attached, which fixes the problem for the Makefile.lite and Visual

Erik de Castro Lopo wrote: >> Currently functions in win_utf8_io.c are a compatibility layer for >> libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC. > > Ok, lets do it. I just thought that it's more complicated. All *file* functions should really be moved to libFLAC. But other functions should not, because libFLAC doesn't use them. Two of them -

Evan Ramos wrote: >> So currently libFLAC on _WIN32 does depend on win_utf8_io. > > Does my patch fix this issue on your end? BTW, your patch also changes MSVC solution/projects. What's the problem with them? I built flac/metaflac/libFLAC libraries with Visual Studio many times, and haven't noticed anything wrong.

Evan Ramos wrote: > > Yes please. > > Patch attached. Sorry, I misunderstood your intention. The utf8_static library should stay as a separate component, but should be statically linked as needed (ie its only needed for Windows) Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Martijn van Beurden wrote: > I just checked on my Raspberry pi (armv6-hf, GCC 4.6) and it > looks like decoding is actually faster with these changes. I > benchmarked 1b8af6b against f7c52c8, the results are attached. Interesting results, thanks. (OTOH, GCC 4.6 was released ~4.5 years ago, so it would be also interesting to test it on newer compilers - GCC 4.9.x or 5.x, or some new

Dave Yeo wrote: > Seems that the default binutils on OS/2 is too old to support AVX2, > attached patch works around this. Not the best solution as best would be > configure tests, but simple. Are you sure that these binutils support AVX and FMA? (Currently libFLAC doesn't contain AVX and FMA instructions). If they aren't supported then it's better to include them too into

Hi all, I have a new pre-reelase (with a GPG signature) up here: http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz.asc This code is built from commit 10a28d482a8e48b806f61ab766992b2add98ec43 plus another commmit to change the version numbers which I will not be pushing to the public repo before the final release. Note that audio files encoded

Dear FLAC devs, I would like to get some of our patches merged into master. Most of them deal with adhering to GNU conventions, respectively not overriding flags/variables that are up to the user to set. For instance, honoring $(htmldir) is important, as we have installation paths for the documentation that differ from what is currently coded in the various Makefile.am's. Regards David

Martijn van Beurden wrote: > Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. > > > CC lpc_intrin_sse2.lo > > CC lpc_intrin_sse41.lo > > CC md5.lo > > md5.c: In function

Evan Ramos wrote: > If so, I can provide a patch that does this. Yes please. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/