similar to: Shared library won't build when cross-compiling.

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc specific optimizations (2012-03-28 15:43:48 -0300) are available in the git repository at: git://github.com/crrodriguez/flac.git master for you to fetch changes up to 3a060556772c5d6a6464afddfda7c3ad2f93a306: Remove winamp2 plugin.

/usr/bin/ld: bad -rpath option collect2: ld returned 1 exit status make[4]: *** [libFLAC.la] Error 1 --- flac-1.1.2/src/libFLAC/Makefile.in.orig 2005-02-04 21:23:37.000000000 -0500 +++ flac-1.1.2/src/libFLAC/Makefile.in 2006-04-30 20:30:00.000000000 -0400 @@ -399,7 +399,7 @@ rm -f "$${dir}/so_locations"; \ done libFLAC.la: $(libFLAC_la_OBJECTS)

Hi Josh (and everyone else on the list), Here's a quick fix for libFLAC.m4 and libFLAC++.m4 for a problem that crops up if you use the macros in an environment where LD_LIBRARY_PATH is set. The macros save LD_LIBRARY_PATH as ac_save_LDPATH, but restore it from ac_save_LD_LIBRARY_PATH. This patch changes ac_save_LDPATH to ac_save_LD_LIBRARY_PATH. Without this, LD_LIBRARY_PATH effectively gets

Yes, it's finally here. See the homepage for details, but here's a summary: - 10-15% decoder speedup - 24-bit input support restored - more robust plugins - new metadata block for Vorbis-style tags - vastly improved metadata editor - fixed bug with pipes and Windows - new libFLAC++, a C++ object wrapper around libFLAC - new metadata editing interface in libFLAC and libFLAC++ - and

On 2006-03-09 (Thu) ,at 23:20:50 Josh Coalson wrote: > the vorbiscomments are not in the streaminfo. you want to do: > > FLAC::Metadata::VorbisComment tags; > if (FLAC::Metadata::get_tags("somefile.flac", tags)) { > FLAC::Metadata::VorbisComment::Entry entry = > tags->get_comment(tags->get_num_comments-1); //e.g. last tag > // do something with

--- src/libFLAC++/Makefile.am | 2 +- src/libFLAC/Makefile.am | 2 +- src/metaflac/Makefile.am | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libFLAC++/Makefile.am b/src/libFLAC++/Makefile.am index 6bd1657..12dfe69 100644 --- a/src/libFLAC++/Makefile.am +++ b/src/libFLAC++/Makefile.am @@ -44,7 +44,7 @@ EXTRA_DIST = \ libFLAC++.m4 # see

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

Seeing how http://flac.sourceforge.net/license.html stresses that libflac and libflac++ are licensed under the New BSD License, would it be possible to relicense include/share/alloc.h from GPL 2.1+ to the New BSD License so that all of libflac and libflac++ become licensed under the New BSD License as intended? Best Regards Magnus Blomfelt

On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:

Hi all, I am interested in building a stand alone Rice Encoder/Decoder, using FLAC source code as a starting point. I've read the theory behind it, and I am very interested in info theory. However, I am struggling with how exactly I would implement the theory in code. I'm a newbie to computer science (only 1 year experience). I have read the format and documentation links on the FLAC

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

I feel really silly asking this, but where is read_residual_partitioned_rice > > _() ? I tried using the standard find feature on text editors for all of > the .c and .cpp files in libFLAC and libFLAC++, but nothing came up. -Mary On 7/11/06, Ralph Giles <giles@xiph.org> wrote: > > On Tue, Jul 11, 2006 at 04:17:41PM -0700, Mary Amon wrote: > > >

Hi I have a problem now cross-compiling FLAC from latest git. With Ubuntu 12.04 and g++-mingw-w64-i686 (4.6.3-1ubuntu5+5ubuntu1). I think that the problem might have been introduced on 5 Mar 2013 with commit 05609d5 (configure.ac : Add hardening compile options.) Gives errors like this:- /home/user/FLAC_build/flac-05609d5/src/libFLAC/.libs/libFLAC.a(ogg_helper.o):ogg_helper.c:(.text+0x173):

Attached is a patch that adds 5 missing FLAC__metadata_object_vorbiscomment_* functions to the VorbisComment class. In my previous message I stated 8 functions were missing, but on closer inspection, 3 of those belong in the VorbisComment::Entry class, and 2 of them already have equivalent functions in there. The last one (FLAC__metadata_object_vorbiscomment_entry_matches()) does not, but I have

Hi all, I've made a test release for Ogg DirectShow Codecs. You can find it here: http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe The problem is that I get a HEAP Corruption detected at: void FLAC__bitreader_free(FLAC__BitReader *br) { FLAC__ASSERT(0 != br); if(0 != br->buffer) free(br->buffer); The call stack is: >

Hi all, I've made a test release for Ogg DirectShow Codecs. You can find it here: http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe The problem is that I get a HEAP Corruption detected at: void FLAC__bitreader_free(FLAC__BitReader *br) { FLAC__ASSERT(0 != br); if(0 != br->buffer) free(br->buffer); The call stack is: >

Yeah, de-/encoding a stream would have a lot of advantages but there is no streaming en-/ decoder I would be aware of and for the application I'd intend to use it for, it might be sufficient to de-/ encode a file in whole. Dependent of the time and efforts for creation and maintenance of a stream encoder, it might not fit into the time budget. (Apart from that, as of now, it gives a nice demo