Re: [flac-dev] flac 1.3.0pre2 pre-release
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 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. See 6.7.4 of the C99 spec for details. I don't see the problem. What exactly is the compiler error? It seems the declarations in the header files don't have inline and they are included with the definitions, so they shouldn't be inline definitions and should be callable from other units. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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. See 6.7.4 of the C99 spec for details. I've read section 6.7.4 from here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf My reading of that section suggests that the usage in FLAC is valid and correct. As for the addition of safe_malloc_mul_2op_ to file src/share/utf8/utf8.c, that simply should not be necessary. I suggest this is an error in the Visual Studio project files. 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 1.3.0pre2 pre-release
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 difficult to review because of its size. Sorry, I'm new at this. I don't know how things should be handled. And I had to do some more inline changing to get my MSVC 2012 to compile the sources. I would still like to have this problem explained to me. 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(stream_decoder.obj) flac Error2error LNK2001: unresolved external symbol _FLAC__bitreader_is_consumed_byte_aligned G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error3error LNK2001: unresolved external symbol _FLAC__bitreader_read_uint32_little_endian G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error4error LNK2001: unresolved external symbol _FLAC__bitreader_get_input_bits_unconsumed G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error5error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_uint64 G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error6error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_int32 G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error7error LNK2001: unresolved external symbol _FLAC__bitwriter_write_byte_block G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error8error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_uint32_little_endian G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error9error LNK2001: unresolved external symbol _safe_malloc_mul_2op_ G:\Programming\flac-1.3.0pre2\src\flac\utf8_static.lib(utf8.obj) flac Error10error LNK1120: 9 unresolved externals G:\Programming\flac-1.3.0pre2\objs\release\bin\flac.exeflac Error 9 is related to the location of _safe_malloc_mul_2op_. It's easiest to fix by having the code in utf8.c. There may still be some bug in FLAC's large input wav handling as the test FLAC I created by encoding over 22 hours of 24 bit data makes foobar2000 report one sample mismatch in reported and decoded length. Or it's a rounding bug in foobar2000. Is it not possible to test this without involving foobar2000? It is and I actually verified it yesterday. I used the command-line flac to decode the file into RAW format and calculated sample count by dividing it with bytes per sample and channel count. It matched the reported sample count exactly, so it's not a bug in FLAC. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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. See 6.7.4 of the C99 spec for details. I've read section 6.7.4 from here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf My reading of that section suggests that the usage in FLAC is valid and correct. 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, the only definition in bitreader.c has been declared inline. 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 external definition, which a translator may use to implement any call to the function in the same translation unit. As for the addition of safe_malloc_mul_2op_ to file src/share/utf8/utf8.c, that simply should not be necessary. I suggest this is an error in the Visual Studio project files. Correct. Rummaging through the code more, it appears that the 'grabbag_static' project isn't compiling grabbac/alloc.c, which is why this is undefined. When I get to the office I will fix up the project files. -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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, the only definition in bitreader.c has been declared inline. 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 external definition, which a translator may use to implement any call to the function in the same translation unit. My understanding is that it's not an inline definition as there is a non-inline declaration in bitreader.h. If there are no better solutions to fix the problem, I'd suggest to #define inline to nothing for MSVC. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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 external definition, which a translator may use to implement any call to the function in the same translation unit. My understanding is that it's not an inline definition as there is a non-inline declaration in bitreader.h. If there are no better solutions to fix the problem, I'd suggest to #define inline to nothing for MSVC. Looking at the spec again, and using the information in Example 7, I found that if we put the following AFTER the inline definition, it becomes available to other translation units. extern unsigned FLAC__bitreader_get_input_bits_unconsumed(const FLAC__BitReader *br); This appears to be different behavior than other uses of the keyword 'extern' (just like the multiple uses of the keyword 'static'). 6.7.4.7 of the C99 spec suggests that a statement such as the above turns an inline definition into an external definition. Add 'extern' to the .h file is unsafe, as any file that included bitreader.h and chose to define an alternate inline definition (as allowed by the spec) would also end up defining an external definition and would result in duplicate symbols. I will redo the patch with these 'extern' function definitions defined inside the corresponding .c files. Hope that helps. -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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 external definition, which a translator may use to implement any call to the function in the same translation unit. My understanding is that it's not an inline definition as there is a non-inline declaration in bitreader.h. I don't see how that can be the case. The spec explicitly states that inline definitions do not provide an external definition. But it's not an inline definition according to 6.7.4.6 (the sentence before the part you have quoted): If all of the file scope declarations for a function in a translation unit include the inline function specifier without extern, then the definition in that translation unit is an inline definition. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [flac 1.3.0pre2 pre-release] Updates to test suite
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 of 'echo' in favor of 'printf' since echo has many unspecified uses. 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. Thanks! test_libFLAC.sh.patch Description: Binary data test_libFLAC++.sh.patch Description: Binary data test_seeking.sh.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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-extern.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] 2GB limit?
Has the 2/4GB limit been fixed? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] I reinstalled OS X, now FLAC 1.3 git won't compile.
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 Willoughby Sound Consulting On Mar 11, 2013, at 20:36, 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.ac:308: warning: macro 'AM_ICONV' not found in library configure.ac:309: warning: macro 'AM_LANGINFO_CODESET' not found in library glibtoolize: putting auxiliary files in `.'. glibtoolize: linking file `./ltmain.sh' glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. glibtoolize: linking file `m4/libtool.m4' glibtoolize: linking file `m4/ltoptions.m4' glibtoolize: linking file `m4/ltsugar.m4' glibtoolize: linking file `m4/ltversion.m4' glibtoolize: linking file `m4/lt~obsolete.m4' configure.ac:308: warning: macro 'AM_ICONV' not found in library configure.ac:309: warning: macro 'AM_LANGINFO_CODESET' not found in library configure.ac:308: error: possibly undefined macro: AM_ICONV If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:309: error: possibly undefined macro: AM_LANGINFO_CODESET autoreconf: /usr/local/Cellar/autoconf/2.69/bin/autoconf failed with exit status: 1 Marcuss-MacBook-Pro:flac Marcus$ ./configure configure: error: cannot find install-sh, install.sh, or shtool in . ./.. ./../.. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [flac 1.3.0pre2 pre-release] Updates to test suite
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/ reworked some of the functions to make it easier to read and process. I'm also eliminating the use of 'echo' in favor of 'printf' since echo has many unspecified uses. 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. I'd normally say no to a big set of patches like this so close to a final release, but if they only touch tests scripts and when I test them they work on Linux, FreeBSD and OpenBSD, then I'm happy to have them. I'll test this first batch within the next 8-12 hours. Erik Hmm, if this huge patch breaks the tests, how do we know whether 1.3.0 is performing identically to 1.2.1? I'm thinking that there is a possibility that the tests might produce a false positive. It seems safer to only change the library or the tests, but not both at the same time. Maybe the patches to the tests should wait until 1.3.1 Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre2 pre-release
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:53:30.0 -0700 @@ -378,7 +378,7 @@ XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2]) case $host_os in - mingw32msvc | mingw32 | freebsd* ) + mingw32msvc | mingw32 | freebsd* | os2*) # Stack protector not working on these platforms 2013/03/09. ;; *) Dave ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
