Displaying 20 results from an estimated 7000 matches similar to: "Lets do a 1.3.2 release"
2016 Feb 03
2
[PATCH] Fix compilation on OS/2
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
2016 Jan 09
3
Lets do a 1.3.2 release
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
2016 Jan 10
0
Lets do a 1.3.2 release
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
2016 Jan 09
2
Lets do a 1.3.2 release
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
>>
2016 Jan 22
2
Lets do a 1.3.2 release
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
2009 Oct 23
3
rdtsc in userspace
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
2016 Jan 28
2
Lets do a 1.3.2 release
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
2016 Jan 09
0
Lets do a 1.3.2 release
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
2016 Feb 08
0
[PATCH] Fix compilation on OS/2
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,
2017 Jan 06
8
[PATCH 0/5] Allow multiple targets to be disabled
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
2016 Jan 09
2
Lets do a 1.3.2 release
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
2016 Jan 29
2
Lets do a 1.3.2 release
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 -
2016 Jan 16
2
Lets do a 1.3.2 release
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.
2016 Jan 08
3
Lets do a 1.3.2 release
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/
2015 Aug 30
2
Undefined behaviour
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
2016 Jan 18
2
Lets do a 1.3.2 release
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
2019 Jul 14
8
Prelease now available
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
2017 Jan 13
9
Upstreaming Gentoo patches
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
2014 Jun 27
4
Lets work towards a new version
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
2016 Jan 08
2
Lets do a 1.3.2 release
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/