similar to: [PATCH] Add configure check for bswap16

Martijn van Beurden wrote: > Op 04-11-14 om 21:06 schreef Ralph Giles: > > The gcc version #ifdef fix for bswap16 doesn't work for Apple's clang. > > Here's a better fix, which has configure check for it directly. > > > > Fixes build failures on MacOS X. > > I now get an error when compiling on Raspbian (GCC 4.6) Is there a later compiler that might

Hi all, The latest pre-release is here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz but there will probably need to be at least one more. I've tested this on x86_64-linux powerpc-linux i386-openbsd5.2 i386-freebsd9 The majority of changes since the last pre-release is the addition of Janne Hyv?rinen's utf8 I/O functionality. Janne's

make -f Makefile.lite cannot compile test_libFLAC/endswap.c because CPU_IS_LITTLE_ENDIAN definition is missing, and also complains about parentheses in ENDSWAP_16. 1) The first patch adds the definition of CPU_IS_LITTLE_ENDIAN into build/config.mk which allows to build test_libFLAC with Makefile.lite 2) Current ENDSWAP_16 macro (((((x) >> 8) & 0xFF) + ((x) & 0xFF) <<

On Fri, Nov 08, 2002 at 12:39:52PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > I have few notes: > > > > It seems there is changed API in CVS again. So, what about adding > > function like > > unsigned FLAC__format_frame_size(const FLAC__Frame *frame) > > which returns size of the frame in bytes. This

Jenkins build is failing with an unresolved symbol __builtin_bswap16. The jenkins instance is on Debian 6 (oldstable) with gcc 4.4.5, which doesn't provide an implementation for this. Here's a quick patch to provide a fallback, which should unbreak the integration tests. -r -------------- next part -------------- A non-text attachment was scrubbed... Name: bswap16.patch Type:

On Wed, 2015-03-11 at 23:03 +0100, Greg Kurz wrote: > /* The host notifier will be swapped in adjust_endianness() according to the > * target default endianness. We need to negate this swap if the device uses > * an endianness that is not the default (ppc64le for example). > */ > > > > +static uint16_t cpu_to_host_notifier16(VirtIODevice *vdev, uint16_t val) > >

On Wed, 2015-03-11 at 23:03 +0100, Greg Kurz wrote: > /* The host notifier will be swapped in adjust_endianness() according to the > * target default endianness. We need to negate this swap if the device uses > * an endianness that is not the default (ppc64le for example). > */ > > > > +static uint16_t cpu_to_host_notifier16(VirtIODevice *vdev, uint16_t val) > >

On Wed, 11 Mar 2015 21:06:05 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Mar 11, 2015 at 07:04:38PM +0100, Greg Kurz wrote: > > vhost is seriously broken with ppc64le guests, even in the supposedly > > supported case where the host is ppc64le and we don't need cross-endian > > support. > > > > The TX virtqueue fails to be

On Wed, 11 Mar 2015 21:06:05 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Mar 11, 2015 at 07:04:38PM +0100, Greg Kurz wrote: > > vhost is seriously broken with ppc64le guests, even in the supposedly > > supported case where the host is ppc64le and we don't need cross-endian > > support. > > > > The TX virtqueue fails to be

Hi Josh et al, I'm compiling on an Ubuntu Edgy x86 machine. Edgy comes standard with gcc-4.1 and I'm getting a number of warnings: memory.c: In function 'FLAC__memory_alloc_aligned': memory.c:52: warning: cast from pointer to integer of different size memory.c:52: warning: cast to pointer from integer of different size metadata_iterators.c: In function

On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > Ok, what about enabling the 3dnow function in libFLAC by default? > > I think time has shown the function is bugfree... :) > > Yeah, I just haven't done it because I don't remember hearing > feedback from others about using it (or

On 01-04-13 12:40, Erik de Castro Lopo wrote: > I've tested this on > > x86_64-linux > powerpc-linux > i386-openbsd5.2 > i386-freebsd9 I've tested this on x86_64-linux as well, but still no static building possible (see earlier post on this). Someone over at HydrogenAudio has successfully built statically linked, but gets all weird kinds of errors

Ok, what about enabling the 3dnow function in libFLAC by default? I think time has shown the function is bugfree... :) -- Miroslav Lichvar

vhost is seriously broken with ppc64le guests, even in the supposedly supported case where the host is ppc64le and we don't need cross-endian support. The TX virtqueue fails to be handled by vhost and falls back to QEMU. Despite this unexpected scenario where RX is vhost and TX is QEMU, the guest runs well with reduced upload performances... until you reboot, migrate, managed save or in fact

vhost is seriously broken with ppc64le guests, even in the supposedly supported case where the host is ppc64le and we don't need cross-endian support. The TX virtqueue fails to be handled by vhost and falls back to QEMU. Despite this unexpected scenario where RX is vhost and TX is QEMU, the guest runs well with reduced upload performances... until you reboot, migrate, managed save or in fact

--- examples/c/decode/file/main.c | 3 +++ examples/c/encode/file/main.c | 3 +++ src/metaflac/operations.c | 3 +++ src/metaflac/operations_shorthand_cuesheet.c | 3 +++ src/metaflac/operations_shorthand_streaminfo.c | 3 +++ src/share/grabbag/cuesheet.c | 3 +++ src/test_libFLAC/encoders.c

The test script doesn't seem to stop on error. I noticed this in the logs: ++++++ testing level 1 interface simple iterator on read-only file generating FLAC file for test testing 'metadata.flac'... 0... 1... content... PASSED is writable = 1 ERROR: iterator claims file is writable when it should not be ERROR during test_libFLAC FAIL: ./test_libFLAC.sh Platform is a mobile

--- src/libFLAC/bitreader.c | 4 ++-- src/libFLAC/bitwriter.c | 4 ++-- src/plugin_xmms/plugin.c | 2 +- src/share/utf8/charset.c | 1 + src/test_libFLAC++/encoders.cpp | 8 ++++---- src/test_libFLAC/decoders.c | 4 ++-- src/test_libFLAC/encoders.c | 8 ++++---- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/libFLAC/bitreader.c

Erik de Castro Lopo wrote: > JonY wrote: > > > Please do a link time test instead, I am not getting this error and > > would like to keep stack protector on. > > I'll write an m4 macro. I have attampted to write a macro that reliably detects the availability of stack smash protection. I currently have two configurations where my detection says that SSP is available

Hi all, As people may have seen there's a pre-release here: http://downloads.xiph.org/releases/flac/beta/ Specifically: flac-1.3.1pre1.tar.xz : The source code flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries Please test. I'm particularly interested in hearing about the windows binaries which were cross compiled from Linux to Windows. Unfortunately there is a bug