similar to: FLAC currently won't compile for Android [bisected]

2013/5/15 Ulrich Klauer <ulrich at chirlu.de> > > Felix, is HAVE_SYS_PARAM_H set or unset in an Android build? This > information would eliminate one of the possibilities. > > Ulrich > Yes, HAVE_SYS_PARAM_H is set in config.h: #define HAVE_SYS_PARAM_H 1 -------------- next part -------------- An HTML attachment was scrubbed... URL:

Felix Homann wrote: > Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3: It seems Android sys/param.h doesn't define MIN/MAX. Could you try to revert this commit on current master (or simply change line 35 of src/libFLAC/include/private/macros.h back to #if defined(__GNUC__) ) and recompile? Or possibly bisect 03a9e60..master to find out when the

Hi all, Anyone know anything about Windows Universal Platform? Someone raised an issue on github: https://github.com/xiph/flac/issues/32 The `flac_max`/`flac_min` issue is resolved, but the WUP one is not. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2013/5/15 Ulrich Klauer <ulrich at chirlu.de> > Felix Homann wrote: > > > Yes, HAVE_SYS_PARAM_H is set in config.h: > > OK ... Yet still I don't see how a change in > src/libFLAC/include/private/macros.h could affect src/flac/utils.c in > any way. > > Anyone got an idea? I haven't spend too much attention to the errors when bisecting, sorry! The

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

A bug was reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739613 get_console_width() may return 0, and there will be division by 0 in stats_print_name(): console_width = get_console_width(); len = strlen_console(name)+2; console_chars_left = console_width - (len % console_width); A simple patch is attached. -------------- next part -------------- A non-text attachment was

On 22.5.2013 17:03, Felix Homann wrote: > Sorry that it took so long to reply. As mentioned in an earlier mail > my first bisect session wasn't accurate. I've done a new one: > > Here's my patch suggestion but I'm no Android guy. -------------- next part -------------- diff --git a/src/flac/utils.c b/src/flac/utils.c index e908706..6f6382e 100644 ---

Hi! Thanks for maintaining FLAC! I recently started a project to compile parts of the FLAC reference distribution to JavaScript using emscripten. https://github.com/gagern/emflac#readme I'm using the 1.3.1 release and the Makefile.lite build process. I'm including the FLAC reference implementation as a submodule, and so far I managed to compile everything without modifying its

Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3: LANG=C android-make | grep Warning bitreader.c: In function 'FLAC__bitreader_skip_bits_no_crc': bitreader.c:494:4: warning: implicit declaration of function 'MIN' [-Wimplicit-function-declaration] bitreader.c:494:4: warning: nested extern declaration of 'MIN' [-Wnested-externs] bitwriter.c: In

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

When using the -p switch during encoding, the encoder should try different qlp predictor precision steps. However, some faulty code was too severely restricting the possible steps. This patch lifts the restriction to match a restriction coded a little further in the process. This doesn't make using -p worth your while, but at least it doesn't create larger files now ---

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the

hello, asteriskers: I compiled asterisk under arm-linux. i am using asterisk 1.4.2. i can run ./configure and menuselect with embedded modules. but running make comes out errors: ranlib libmxml.a make[3]: Leaving directory `/usr/src/asterisk-1.4.2/menuselect/mxml' cc -Wall -o menuselect.o -g -c -D_GNU_SOURCE menuselect.c cc -Wall -o menuselect_curses.o -g -c -D_GNU_SOURCE

On 04/28/13 02:38 am, Erik de Castro Lopo wrote: > Hi all, > > I have tagged 1.3.0pre4 in git and provided a tarball here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz On OS/2 compile dies here, CC win_utf8_io/win_utf8_io.lo win_utf8_io/win_utf8_io.c:13:75: error: windows.h: No such file or directory ... with lots of more errors. The problem is

Hi all, Nice one for a Friday afternoon ... I'm trying to follow this section of the manual : http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-Undefined-Behaviour-Sanitizer to build R-devel (as of a few hours ago: rev 66684) with -fsanitize=undefined,address. My OS is Linux Mint Debian Edition. To get gcc-4.9 I added Debian testing to my apt sources and ran : sudo

Hello, I've compiled Samba 3.0.4 with Heimdal 0.6.2 and all of the other trimmings to join and ADS tree, which I have successfully done. Winbind correctly pulls all of the username and group information from the ADS tree and all is good. However... I seem to be running into a wall with the wonderful Solaris 8 character username / groupname limit. Usernames with spaces or names longer than

On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > Hi, > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > The kernel is alive because I can switch to VT1 and reboot with > ctrl-alt-delete. > > I bisected the problem down to this commit: > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > >

https://bugs.freedesktop.org/show_bug.cgi?id=50836 Bug #: 50836 Summary: [bisected] ION fails to probe Classification: Unclassified Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=96656 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mesa-dev at lists.freedesktop. |nouveau at lists.freedesktop.o |org |rg QA

https://bugs.freedesktop.org/show_bug.cgi?id=96656 --- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> --- The problem was pre-existing, but a combination of factors made the readpixels cache expose it harder. Fixed by: commit b433cb51e50cab878cbaa023662bacd1f923a183 Author: Ilia Mirkin <imirkin at alum.mit.edu> Date: Thu Jun 23 22:33:59 2016 -0400 nvc0: when mapping