similar to: No subject

Thomas Zander wrote: > In any case, the disable-SSE matter is still important. People are > still using flac on x86 machines without SSE, for instance AMD Geode > CPUs seem to live forever. libFLAC detects CPU SSE support in runtime, so --disable-sse is necessary for cuch CPUs only because it disables -msse2 switch. Maybe it makes sense to add new switch, --no-force-sse2 or

On Fri, Apr 10, 2015 at 1:40 PM, lvqcl <lvqcl.mail at gmail.com> wrote: > Tristan Matthews wrote: > > > if test "x$asm_optimisation$sse_os" = "xyesyes" ; then > > XIPH_ADD_CFLAGS([-msse2]) > > - XIPH_ADD_CFLAGS([-mstackrealign]) > > + if test "$host_os" = "mingw32" ; then >

OS SSE support is now mandatory, so the description of --disable-sse option isn't correct now (actually, it wasn't fully correct even before this). *Currently all it does is disables -msse2 flag* The relevant parts of configure.ac: AC_ARG_ENABLE(sse, AC_HELP_STRING([--disable-sse], [Disable SSE if the OS does not support SSE instructions]), [case "${enableval}" in yes)

--- configure.ac | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index eb9b0cc..4347c07 100644 --- a/configure.ac +++ b/configure.ac @@ -399,9 +399,10 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then if test "x$asm_optimisation$sse_os" = "xyesyes" ; then XIPH_ADD_CFLAGS([-msse2]) - XIPH_ADD_CFLAGS([-mstackrealign]) +

Tristan Matthews wrote: > --- > configure.ac | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index eb9b0cc..e7d68c3 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -399,9 +399,11 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then > > if test "x$asm_optimisation$sse_os" =

Tristan Matthews wrote: > if test "x$asm_optimisation$sse_os" = "xyesyes" ; then > XIPH_ADD_CFLAGS([-msse2]) > - XIPH_ADD_CFLAGS([-mstackrealign]) > + if test "$host_os" = "mingw32" ; then > + XIPH_ADD_CFLAGS([-mstackrealign]) > + fi > fi But sse_os==no doesn't prevent libFLAC from using SSE intrinsics. So I think

And only for i686. --- configure.ac | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index eb9b0cc..8dd5b0d 100644 --- a/configure.ac +++ b/configure.ac @@ -399,11 +399,16 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then if test "x$asm_optimisation$sse_os" = "xyesyes" ; then XIPH_ADD_CFLAGS([-msse2]) -

Bryan Levin reported a problem of the FreeBSD flac port dumping core on FreeBSD 4.x: http://sourceforge.net/tracker/index.php?func=detail&aid=1099004&group_id=13478&atid=113478 It turns out that the port enabled SSE support, but FreeBSD 4.x does not support SSE by default. (FreeBSD 5.x and later do.) I have added a small patch to the port to check at runtime whether the system

On BSD systems, the 64-bit x86 architecture is called "amd64". --- configure.ac.orig 2014-11-27 03:45:33.598155000 +0100 +++ configure.ac 2015-01-09 23:34:27.000000000 +0100 @@ -104,7 +104,7 @@ asm_optimisation=no case "$host_cpu" in - x86_64) + amd64|x86_64) if test $ac_cv_sizeof_voidp = 4 ; then # This must be a 32 bit user space running on 64 bit kernel so treat

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case? What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key? Thanks, Kevin ________________________________________ From: openssh-unix-dev

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

Currently the only way to compile FLAC using GCC w/o SSE support is to disable asm optimizations (see configure.ac): if test "x$asm_optimisation" = "xyes" ; then XIPH_ADD_CFLAGS([-msse2]) fi Also it's not possible to enable SSE4.1 intrinsic functions even with -msse4.1 option. The patch fixes both problems. --------------- BTW: I'm not sure that share/compat.h

This reverts commit 2860f1780ca92c779ee0a2c545ae1b9c4818dc53. Conflicts: configure.ac Do not use -fgnu89-inline as it can emit duplicate symbols for inline functions that are declared in multiple object files being linked together. For example on clang 5.0 targetting iOS (clang advertises itself as gcc 4.2, the last GPL version of gcc) --- configure.ac | 12 ++++-------- 1 file changed, 4

There are problems in the configure option handling code for http streaming that was added to the XMMS plugin for 1.1.2. In configure.c, flac_cfg.stream.proxy_host and other pointers to strings are initialized with pointers to an empty string "". Subsequent code in FLAC_XMMS__init() and flac_configurewin_ok() passes these pointers to g_free(). Since they don't point to memory that

This affects the XMMS plugin. configure.in has this test: AC_CHECK_TYPES(socklen_t, [], []) And src/plugin_xmms/http.c is the only consumer: #ifndef HAVE_SOCKLEN_T typedef unsigned int socklen_t; #endif Together this looks bogus to me. The configure check looks for socklen_t in the default headers. If it isn't found there, socklen_t will be typedef'ed. However, at least on

I'm currently trying to figure out why RC3 oggenc with iconv support will - work, but enter replacement characters into tags instead of converting to UTF-8; - dump core; or - catch an assert(); depending on the locale settings. (On FreeBSD, with Chuguev iconv.) I think I'm getting a handle on the assert(). It's this one: assertion "(!k && !ibl) || (k == (size_t)(-1)

libogg 1.1's included regression tests ("make check") fail at least on alpha: ---------------> ./test_bitwise Small preclipped packing (LSb): ok. Null bit call (LSb): ok. Large preclipped packing (LSb): ok. 32 bit preclipped packing (LSb): ok. Small unclipped packing (LSb): ok. Large unclipped packing (LSb): ok. Single bit unclipped packing (LSb): ok. Testing read past end