On Sat, Mar 09, 2013 at 12:28:28PM -0500, Ben Allison wrote:
> Erik,
>
> Sorry for the confusion. There is one more patch. I had it in the first
> attempt I made but somehow these changes weren't in the redone patch.
>
> As mentioned before, this removes some of the 'inline' from the bitreader
Martijn van Beurden wrote:
> If this stuff was already on someone's TODO list or some release
> checklist, sorry for wasting your time, I just wanted to be sure. :)
Yes, its all on the list :).
Cheers,
Erik
--
--
Erik de Castr
Janne Hyvärinen wrote:
> Here's a patch that fixes the creation of larger than 2 GB FLAC files.
> Without this patch both GCC and MSVC compiles of FLAC will fail on
> Windows when they have written 2 GB file while encoding from stdin. And
> after 4GB when encoding from WAV file.
Ok.
> It incl
Ben Allison wrote:
> As mentioned before, this removes some of the 'inline' from the bitreader
> and bitwriter functions that were used in another translation unit. I'm
> surprised that this code works on other platform. It must be a bug in
> GCC, or maybe deliberately non-standard behavior.
On 11.3.2013 13:05, Erik de Castro Lopo wrote:
>> It includes Ben Allison's MSVC changes and JonY's MinGW changes with
>> some tweaks to make both environments happy.
> Please don't do that. Adding bits of other patches makes it more
> difficult to evaluate and review this patch which is already d
> Ben Allison wrote:
>
>> As mentioned before, this removes some of the 'inline' from the
>> bitreader
>> and bitwriter functions that were used in another translation unit.
>> I'm
>> surprised that this code works on other platform. It must be a bug in
>> GCC, or maybe deliberately non-standard b
On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
> Take, for example, the function FLAC__bitreader_is_consumed_byte_aligned.
> It is prototyped in bitreader.h It is used in stream_decoder.c, so it
> must be defined and made available to the linker ("external definition").
> However, t
> On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
>> From 6.7.4.6
>> An inline definition does not provide an external definition for the
>> function, and does not forbid an external definition in another
>> translation unit. An inline definition provides an alternative to an
>> extern
On Mon, Mar 11, 2013 at 08:51:43AM -0400, Ben Allison wrote:
> >> From 6.7.4.6
> >> An inline definition does not provide an external definition for the
> >> function, and does not forbid an external definition in another
> >> translation unit. An inline definition provides an alternative to an
> >
Janne Hyvärinen wrote:
> With the sources as they are compiling produces these errors (this on
> MSVC 2012 SP1 Express):
>
> Error1error LNK2001: unresolved external symbol
> _FLAC__bitreader_bits_left_for_byte_alignment
> G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(strea
Hi all,
I'm currently going through the massive test suite, updating all the
scripts making sure they conform to the POSIX standard.
I've added a bunch of comments to them and have slightly changed/reworked
some of the functions to make it easier to read and process.
I'm also eliminating the use
>> On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
> I will redo the patch with these 'extern' function definitions defined
> inside the corresponding .c files.
As promised, here is the patch to declare the inline functions as external
definitions.
-Ben Allison
FLAC-1-3-0-inline-ext
Has the 2/4GB limit been fixed?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Marcus Johnson wrote:
> Has the 2/4GB limit been fixed?
There are at least three 2/4G issues:
a) Encoding flac from WAV/AIFF files which are more than 4G in size
(and hence mal-formed according to the WAV/AIFF spec). Fixed and
documented using the --ignore-chunks-sizes flac command line
Marcus Johnson wrote:
> Are there any dependencies that I need, but don't have? I've got doxygen,
> libogg, automake, autoconf, libtool, valgrind, docbook, nasm, yasm,
> libiconv.
>
> the Autogen.sh script fails with:
>
> "Updating build configuration files for FLAC, please wait
> configure.
When you reinstalled OSX, did you also reinstall the developer tools?
I often forget that extra step. I assume you did, otherwise you
wouldn't have gcc or make, but I figure it's worth asking. Also,
there are option Unix tools that usually aren't installed unless you
ask for them.
Brian Wi
Jaren Stangret wrote:
> Hi all,
>
> I'm currently going through the massive test suite, updating all the
> scripts making sure they conform to the POSIX standard.
>
> I've added a bunch of comments to them and have slightly changed/reworked
> some of the functions to make it easier to read and p
On Mar 11, 2013, at 21:37, Erik de Castro Lopo wrote:
> Jaren Stangret wrote:
>
>> Hi all,
>>
>> I'm currently going through the massive test suite, updating all the
>> scripts making sure they conform to the POSIX standard.
>>
>> I've added a bunch of comments to them and have slightly changed/
Hi,
On 03/09/13 03:37 am, Erik de Castro Lopo wrote:
> Hi all,
>
> Second and hopefully final pre-release is here:
>
> http://downloads.xiph.org/releases/flac/beta/
OS/2 now needs this patch.
--- configure.ac.orig 2013-03-11 21:52:54.0 -0700
+++ configure.ac2013-03-11 21:
Ben Allison wrote:
> >> On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
> > I will redo the patch with these 'extern' function definitions defined
> > inside the corresponding .c files.
>
> As promised, here is the patch to declare the inline functions as external
> definitions.
Tha
Dave Yeo wrote:
> OS/2 now needs this patch.
> --- configure.ac.orig 2013-03-11 21:52:54.0 -0700
> +++ configure.ac2013-03-11 21:53:30.0 -0700
> @@ -378,7 +378,7 @@
> XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2])
>
> case "$host_os" in
> - mingw32msvc | mingw32 | freebs
Brian Willoughby wrote:
> Hmm, if this huge patch breaks the tests, how do we know whether
> 1.3.0 is performing identically to 1.2.1?
The only way I can conceive of this "breaking the tests" is by
making the test fail in a very obvious manner.
> I'm thinking that there is a possibility that
Jaren Stangret wrote:
> Attached are only three patches (each patch is for a different test
> script). If everyone is happy with these three patches, I'll continue and
> rework the rest of the scripts.
These look good so far. I've commited them to a branch. When I
get the rest I'll test them th
23 matches
Mail list logo