similar to: flac 1.3.0pre1 prelease

Martijn van Beurden wrote: > > 'chown', declared with attribute warn_unused_result [-Wunused-result] > > metadata_iterators.c:3299:2: warning: ignoring return value of > > 'chown', declared with attribute warn_unused_result [-Wunused-result] > > In file included from /usr/include/stdio.h:934:0, Thats an Ubuntu special. They have patched their libc headers

On 03-03-13 00:22, Erik de Castro Lopo wrote: > I have personally tested this code on: > > x86-linux > x86_64-linux > powerpc-linux Have you tried static building too? I just tried a bunch of switches for ../configure and both "--enable-static" as well as "--disable-shared --enable-static" fails for me on Kubuntu 12.04 64-bit with the following

Andy Hawkins wrote: > Hi, > > In article <20130304070023.141c9f101622a34c46d68c80 at mega-nerd.com>, > Erik de Castro Lopo<mle+la at mega-nerd.com> wrote: > >> project tends to be a pain unless one of the principal developers is using > >> it on a daily basis (as I know you've experienced with libsndfile, Erik). > > > > Yes,

https://git.xiph.org/?p=flac.git;a=commit;h=91790ef965553fd6d76e1f51b55dc4de3b54ad4b It (among other things) changes (void)chown(...) into FLAC_CHECK_RETURN(chown(...)). I don't know what warning "(void)chown(...);" raises, and I cannot test it because I don't have Linux, but FLAC_CHECK_RETURN calls printf, and IMHO the library function shouldn't do it. So it makes sense to

Ben Allison wrote: > Visual Studio files (which don't use config.h, but define various things > in the project settings) are compiling with the wrong FLAC version string > (1.2.0 or 1.2.1) Is there really no other way to set the version string? > I've attached the patch. Thanks. I'm wondering if it really should be 1.3.0 and not 1.3.0pre1 which is more accurate at least

Visual Studio files (which don't use config.h, but define various things in the project settings) are compiling with the wrong FLAC version string (1.2.0 or 1.2.1) I've attached the patch. Maintaining Visual Studio project files in a cross-platform open-source project tends to be a pain unless one of the principal developers is using it on a daily basis (as I know you've experienced

There's a more few issues for compiling on MSVC. I put together a patch. Here's a quick rundown: * must use __inline keyword with static inline functions (bitmath.h) * change instances of uint32_t in bitwriter.c to FLAC__uint32 * functions marked inline cannot be used within another C file (e.g. FLAC__bitreader_get_input_bits_unconsumed produces the linker error "error LNK2001:

Ben Allison wrote: > Here's another go at it. I only have VS2008 and VS2010 to test with right > now. VS6.0, VS2003 and VS2005 are untested. Thanks for your work on this Ben. > I would recommend using FLAC__uint32 instead of uint32_t to avoid these > small #if _MSC_VER < xxxx things everywhere, although I completely > understand the desire to use C99 types. If we add

On 3/5/2013 7:54 AM, Erik de Castro Lopo wrote: > Cristian Rodr?guez wrote: > >> On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote: >> >>> May look at CMake after this current release. >> That will make the situation reverse, that is, better for windows, >> insane for the rest of the world. > *If* I get around to it, it will be in a branch, not in

On 13-03-04 12:05 PM, Andy Hawkins wrote: > Not sure if you've considered it, but cmake allows you to generate Visual > Studio project files automatically, while still allowing cross platform > builds. Does this still require a Visual Studio install? If so this feature isn't much help for developers based on non-Windows systems. -r

On 13-03-05 10:50 AM, Andy Hawkins wrote: > Yes, all CMake does is generate the files appropriate for your build system > (Makefiles for linux, Visual Studio project files for Windows). I meant that CMake cannot generate Visual Studio project files for Windows without an actual Windows environment with a copy of Visual Studio. What would really help Linux- (or Mac-) based developers would

Ben Allison wrote: > >> * change instances of uint32_t in bitwriter.c to FLAC__uint32 > > > > Can we include <inttypes.h> to fix this instead? > > Sadly there is no inttypes.h on MSVC. At least versions to Visual Studio > 2010. I presume this is why ordinal.h was created in the first place. I'm not sure how Josh came to do it that way. In general, I

Ben Allison wrote: > There's a more few issues for compiling on MSVC. I put together a patch. > > Here's a quick rundown: > * must use __inline keyword with static inline functions (bitmath.h) If you include "share/compath.h" you will get a inline #defined as __inline when _MSC_VER is defined. I'd prefer a single diffinition of that in one place and one place

Cristian Rodr?guez wrote: > On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote: > > > May look at CMake after this current release. > > That will make the situation reverse, that is, better for windows, > insane for the rest of the world. *If* I get around to it, it will be in a branch, not in mainline. I see FLAC as FOSS/libre software. It is firmly targeted at

Johnny Rosenberg wrote: > Maybe a stupid question, but I was born stupid and I have walked that > path ever since, so: Is there a changelog? The only changelog is the git changelog. I will be writing a real changelog to go in the actual release tarball before the official release. The git changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of

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

JonY wrote: > What is your link test checking and how does it fail? My m4 macro is really simple, TRY_LINK a simple program with the stack protect CFLAGS: AC_DEFUN([XIPH_GCC_STACK_PROTECTOR], [AC_LANG_ASSERT(C) AC_MSG_CHECKING([if $CC supports stack smash protection]) xiph_stack_check_old_cflags="$CFLAGS" SSP_FLAGS="-fstack-protector --param ssp-buffer-size=4"

Janne Hyv?rinen wrote: > Patch v2, now handles more malformed cases. Original patch was for a > file for which I had a sample from a user but this allows handling some > manually broken test cases. Err, I'm getting warning messages on that patch: CC metadata_iterators.lo metadata_iterators.c: In function ?read_metadata_block_data_vorbis_comment_cb_?:

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

Dear R People: I am attempting to install SparseM on R 2.15.0 on a Linux 11.10 system. Here is the output > install.packages("SparseM",depen=TRUE) Installing package(s) into ?/home/erin/R/x86_64-pc-linux-gnu-library/2.15? (as ?lib? is unspecified) --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done trying URL