similar to: FLAC 1.2.0 won't build without ogg

I just tried to build 1.2 on my Macbook i ran configure with the following arguments (like i have in the past) ./configure --enable-static --disable-asm-optimizations --disable-shared then "make: i get the following error: encode.c: In function 'convert_to_seek_table_template': encode.c:2181: error: 'struct <anonymous>' has no member named 'use_ogg'

On 6/3/06, Avuton Olrich <avuton@gmail.com> wrote: ...stuff... I just ran gdb on it, when it got to the point that it goes no further I sent kill -11 and got the following (hope it helps): Core was generated by `flac -o hs.flac -0 --force-raw-format --channels=2 --bps=16 --sample-rate=44100'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for

On Fri, Jul 20, 2001 at 08:14:55PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > > > > > This version seems to work at least partially on ia64. I am able > > to encode my > > > usual test WAV file now, but I still get a segfault during the > >

I'm attempting to flac a 18GB raw file, and as per 1328191 I compiled CVS, when it gets to 4GB it doesn't continue. I've tried stracing and get no output after a certain point. I also have tried oggflac and it is no different. I configured with no options or special CFLAGS and this is on a x86 machine. Is there anything special I need to do to get this to work? I have also tried with

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote: > There have been reports of -9 using huge amounts of memory. -9 is really > theoretical, but people always seem to want to try the max setting. Anyway, > that's not an excuse but figuring out why -9 is using so much memory is lower > on my list than other stuff. -8 should get within 0.01% of -9 and is pretty >

--- Matt Zimmerman <mdz@debian.org> wrote: > On Fri, Jul 20, 2001 at 08:14:55PM -0700, Josh Coalson wrote: > > > --- Matt Zimmerman <mdz@debian.org> wrote: > > > On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > > > > > > > This version seems to work at least partially on ia64. I am > > > able > > > to

(I am not on this list, please CC me manually if necessary) On Fri, Mar 15, 2002 at 11:47:15PM -0500, Asheesh Laroia wrote: > Are you sure it's not your compiler? That's the first thing I would > check. I know that RedHat is famous for including broken pre-releases of > GCC in their distributions since 7.0. FUD. Please stop that, it makes you look unprofessional. Until you can

On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > This version seems to work at least partially on ia64. I am able to encode my > usual test WAV file now, but I still get a segfault during the self-tests. Interestingly enough, when I recompiled with --enable-debug to get a stack trace, it worked. Any ideas how to track down the problem? -- - mdz

Hi Josh, Here are all the patches that are currently applied to the Debian packages for flac. You may disagree with some of them but as the current maintainer, I'm submitting them all for your consideration. (I should've submitted them earlier, but I've been quite busy. Sorry!) Here is a listing of the patches that I'll be sending: Patch 1 fixes a simple typo in metaflac

--- include/share/compat.h | 8 ++++++++ src/flac/main.c | 37 +------------------------------------ src/share/grabbag/seektable.c | 31 +------------------------------ 3 files changed, 10 insertions(+), 66 deletions(-) diff --git a/include/share/compat.h b/include/share/compat.h index e9ac958..ff5c8af 100644 --- a/include/share/compat.h +++ b/include/share/compat.h

> > I also had this verify error encoding a wav I ripped from a CD. I > didn't > > report this as it happended on flac running on debian linux > -current unstable. > > This error happened only with one track of a CD I was ripping. > > > > Another reason for me not reporting this was, that flac 1.0 running > on OpenBSD > > 2.9 encoded the wav with

I have noticed flac -S- isn't working correctly, '-' isn't handled in parse_option() nor in convert_to_seek_table_template(). It makes SEEKTABLE with one seek point. Similar options -V-, -e-, -p-, ... are not allowed since 1.0.4, I think best would be drop -S- from documentation too and use --no-seektable option only. -- Miroslav Lichvar

1) changelog.html "Add ability to handle utf8 filenames on Windows (large set of patches from Janne Hyv?rinen)" AFAIK Windows internally uses UTF-16LE, not UTF-8. IMHO it's better to use a general word 'Unicode' instead of 'utf8'. 2) documentation_bugs.html "The following are major known bugs in the current (1.2.1) release:" 1.2.1 is not the current

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 have an Intel Mac and I'd be glad to test it for you, but I'm not sure how to use the makefile.lite build system? do I just replace the normal one with this one? I tried ./makefile.lite but nothing happened. On Sun, Jul 20, 2014 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To

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`

https://bugzilla.samba.org/show_bug.cgi?id=8342 Summary: rsync can't handle populate dirs without u+rx permissions Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org

On Oct 21, 2008, at 10:16 AM, David Greene wrote: > On Monday 20 October 2008 16:14, Chris Lattner wrote: > >> Ok, if you need this direction, just use an >> std::vector<pair<unsigned,Instruction*>> as a forward map? You can >> do >> fast binary searches in it. > > I don't see how that helps. I need a map from BasicBlock to a list > of

Hi All, I have a really strange issue occuring where if I run "show dialplan" or "dialplan show" or "dialplan show parkedcalls", then asterisk dumps core. It only appears to happen with contexts that are created within res_features. I am able to display all my other dialplans, but, every time I try to just do a normal "dialplan show" asterisk core dumps

On Monday 20 October 2008 16:14, Chris Lattner wrote: > Ok, if you need this direction, just use an > std::vector<pair<unsigned,Instruction*>> as a forward map? You can do > fast binary searches in it. I don't see how that helps. I need a map from BasicBlock to a list of loads and stores. > > I suppose we could resctrict the map to containing only load and