Displaying 20 results from an estimated 300 matches similar to: "Upstreaming Gentoo patches"
2017 Jan 15
4
Updated CFLAGS patches and make test compilation conditional
Hi Erik,
I've found a middleground for the problem of setting default CFLAGS. I've gone back
to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script
(i.e., the user hasn't specified anything) and then proceed to set them to the defaults
as before. This has been suggested before:
https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html
In
2017 Jan 13
0
[PATCH 1/4] Do not override CFLAGS, as CFLAGS is a user flag.
* Furthermore, use NDEBUG globally to detect the presence
of building with more debug output information.
AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays
Gnome has also switched to it from its own custom solution.
---
configure.ac | 19 +------
include/FLAC/assert.h | 2 +-
m4/ax_check_enable_debug.m4 | 124 ++++++++++++++++++++++++++++++++++++++++++
2017 Jan 15
0
[PATCH 1/2] Do not override CFLAGS, as CFLAGS is a user flag.
* Furthermore, use NDEBUG globally to detect the presence
of building with more debug output information.
AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays
Gnome has also switched to it from its own custom solution.
---
configure.ac | 52 ++++++++++++------
include/FLAC/assert.h | 2 +-
m4/ax_check_enable_debug.m4 | 124
2013 Oct 09
3
PATCH for rice_parameter calculation
MSVS profiler shows that the following code in stream_encoder.c takes
several percent of CPU time:
for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1)
;
this code is equivalent to:
rice_parameter = 0; k = partition_samples;
while(k < mean) {
rice_parameter++; k <<= 1;
}
The idea was to accelerate it:
2013 Oct 11
1
PATCH for rice_parameter calculation
Or, I was originally thinking:
rice_parameter = 0; k = partition_samples;
if (k < mean) {
int n = mean - k;
rice_parameter += n;
k <<= n;
}
(sorry for the hasty post)
On Oct 11, 2013, at 10:34, Brian Willoughby wrote:
> Hmm, maybe I'm missing something, but what about this:
>
> rice_parameter = 0; k = partition_samples;
> int n = mean - k;
> if (n >
2007 Apr 05
2
FLAC 24 bit test results
On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote:
> Josh (Green),
>
> Seems like the longest example in your list is a 15-second file. I
> would like to see the same problem exhibited in a file that is of a
> normal length. I have been recording full performances lasting
> hours, and flac always compresses the files below 70% of the original
> size.
>
2016 Jan 30
2
[PATCH] remove plugin_common library from MSVC
Previously src/plugin_common library was used by flac own
Winamp plugin (MSVC/Windows) and by XMMS plugin (*nix).
The Winamp plugin is long gone from flac tree, so plugin_common
is unused on Windows. This patch removes it from MSVC project files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove_plugin_common_from_msvc.patch
Type: application/octet-stream
2020 Jul 02
2
Possible overflow of _candidate_bits in stream_encoder.c
Recently I was trying some new approaches to improve FLAC compression, when
I stumbled on a possible overflow. The reason this has not come up earlier
is because the encoder only hits this point when the estimate of the
rice_parameter is very much off.
To trigger this overflow, one has to force rice_parameter to 0 in for
example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c.
When
2006 Jul 23
1
[PATCH] Fix a compile bug with gcc 2.95 in src/plugin_common/replaygain.c
Declaring variables in the middle of a block isn't supported by
older (pre-C99?) compilers, and gcc 2.95 is one of them.
--- a/src/plugin_common/replaygain.c
+++ b/src/plugin_common/replaygain.c
@@ -28,10 +28,11 @@ void FLAC_plugin__replaygain_get_from_fi
double *track_peak, FLAC__bool *track_peak_set,
2013 Jul 21
3
exhaustive-model-search issue results in multi-gigabyte FLAC file
Miroslav Lichvar wrote:
> On Wed, Jul 17, 2013 at 07:45:53PM +1000, Erik de Castro Lopo wrote:
> > The fix was changing one local variable from FLAC_uint32 to FLAC_uint64
> > in function precompute_partition_info_sums_().
> >
> > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b
>
> I don't like this fix. It will
2011 Aug 19
2
[LLVMdev] building LLVM for i386 under snow leopard
Hello, Does anyone know how to build LLVM for the i386 architecture
with snow leopard (this seems to have been the default for leopard).
I've tried building with:
./configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" LDFLAGS="-arch
i386" OBJCFLAGS="-arch i386" --prefix=/Users/keith/share/
--enable-shared --enable-jit && make
but I still end up
2004 Sep 10
3
id3v2 problem
Hi Josh,
I found id3v2 didn't work on v1.1.0. I checked source codes, macros- (in
such cases as FLAC_HAVE_ID3LIB) ware moved to config.h. That is good.
But the place to do include is the after of #ifdef FLAC_HAVE_ID3LIB.
The result of configure script isn't reflected. And it doesn't always
have id3lib with this.
Move place of 'include "config.h"' to the top. I
2009 Jul 23
1
problem building R 2.9.1 from source on RHEL 4 (x86_64)
I am building from source on RHEL 4 and have run into a
problem while running "make check":
running code in 'lapack.R' ...make[3]: *** [lapack.Rout] Error 1
make[3]: Leaving directory `/opt/R/R-2.9.1/tests'
make[2]: *** [test-Specific] Error 2
make[2]: Leaving directory `/opt/R/R-2.9.1/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving
2004 Sep 10
1
plugin optimizations
Here is all-in-one patch, if this is a problem, i will try to make
separated patches.
Changes:
plugin_common/
* FLAC__plugin_common__pack_pcm_signed_little_endian
* accept FLAC__int32 *input[]
* supports more channels
* fixed clipping bug
(BTW, random number generator in dither.c is low quality, it
should be replaced, generator in replaygain is much better)
*
2004 Sep 10
2
xmms-flac plugin in OS X - Apple X11
I have been using Apple's X11 on OS X and I got the source and compiled
flac 1.0.5 beta2. Everything seemed to build and install OK, but the
xmms-flac plugin is not working, and I cannot open xmms. I get the
following error when I launch xmms from xterm:
brian it's 8:41pm, what now? xmms &
[1] 567
brian it's 8:41pm, what now? dyld: xmms Undefined symbols:
2004 Sep 10
1
[Flac-users] Undefined PLT symbol "FLAC__plugin_common__init_dither_context"
Well, I've rebuilt flac from the original source, without using the NetBSD
package system, and I'm still seeing the same problem with the XMMS FLAC
plugin:
/usr/pkg/lib/xmms/Input/libxmms-flac.so: Undefined PLT symbol "FLAC__plugin_common__init_dither_context" (symnum = 30)
I can see that the symbol is defined in the common library:
$ nm src/plugin_common/libplugin_common.a |
2012 Dec 12
8
[PATCH 0/5] update build system
This patch series modernizes various aspects of the autotools
based build system. There is a lot more that could and should be
done, but I tried to stay conservative for now and just resolve
some of the most obvious issues.
Max Horn (5):
configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN
autogen.sh: replace this by a simple call to autoreconf
configure: always print
2004 Sep 10
2
And Another OS X Install Problem...
/bin/sh ../../mkinstalldirs /sw/lib/xmms/Input
../../libtool-disable-static --mode=install /usr/bin/install -c
libxmms-flac.la /sw/lib/xmms/Input/libxmms-flac.la
libtool-disable-static: install: warning: relinking `libxmms-flac.la'
cd /Users/glenn/Desktop/flac-1.0.5_beta1/src/plugin_xmms; /bin/sh
../../libtool-disable-static --mode=relink gcc -I../.. -I./include
-I../../include -g -O2
2011 Aug 19
0
[LLVMdev] building LLVM for i386 under snow leopard
Hi Keith,
> Hello, Does anyone know how to build LLVM for the i386 architecture
> with snow leopard (this seems to have been the default for leopard).
> I've tried building with:
>
> ./configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" LDFLAGS="-arch
> i386" OBJCFLAGS="-arch i386" --prefix=/Users/keith/share/
> --enable-shared
2014 Jun 19
5
[PATCH] stream_encoder : Improve selection of residual accumulator width
On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote:
> BTW, what can you say about the following place in stream_decoder.c
> in read_subframe_lpc_() function:
>
> /*@@@@@@ technically not pessimistic enough, should be more like
> if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)