similar to: [PATCH] unnecessary assignment

The replay gain code has dos line endings in CVS, which causes problems for the Sun compiler, among others. Attached is a patch for the lazy, but it's probably easier to fix locally and commit. -r

On Sat, Jun 04, 2005 at 08:00:45AM -0700, Ralph Giles wrote: > The replay gain code has dos line endings in CVS, which causes problems > for the Sun compiler, among others. Attached is a patch for the lazy, > but it's probably easier to fix locally and commit. Now with actual patch... -r -------------- next part -------------- Index:

Josh: > fixed, thanks! Thanks. However, I think there is a better patch to fix these problems. I reworked this patch not long ago to do better testing for what inline to use in configure, and also a better way to calculate the size of the #defines in replaygain_analysis.c. This was submitted to the SourceForge bug tracker as bug 1701960. See here, and note attached patch.

Some projects/makefiles add both 'include' and 'include/share' to the list of additional include directories. For example, src/share/utf8/utf8.c includes 'include/share/alloc.h' as "share/alloc.h" but 'include/share/utf8.h' as just "utf8.h". Also src/share/replaygain_analysis/replaygain_analysis.c includes "replaygain_analysis.h", not

Erik de Castro Lopo wrote: > lvqcl wrote: > > > Some projects/makefiles add both 'include' and 'include/share' > > to the list of additional include directories. > > I think that is suboptimal. > > > For example, src/share/utf8/utf8.c includes 'include/share/alloc.h' > > as "share/alloc.h" but

Thanks for the reply. I would very much like OGG container support, so disabling it isn't really an option. I have built OGG so that it creates a libogg.a, libogg.0.dylib and a symbolically linked libogg.dylib (that links to the libogg.0.dylib) file. If I remove the .dylib files in an attempt to 'encourage' the compiler to use libogg.a, then it complains that it can't find the

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------

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

Hi, I'm trying to build current git on i386, but it fails with the following error: make[3]: Entering directory '/tmp/flac/src/share' CC grabbag/replaygain.lo In file included from grabbag/replaygain.c:38:0: ../../include/share/replaygain_analysis.h:45:15: error: conflicting types for 'float_t' typedef float float_t; /* Type used for filtering */

On Tue, Aug 17, 2010 at 3:12 PM, Paul Davis <paul at linuxaudiosystems.com> wrote: > On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord <glenn.mccord at gmail.com> wrote: > >> libtool: link: gcc -I/Users/glennm/libOGG-i386/include -O3 >> -funroll-loops -finline-functions -Wall -W -Winline -arch i386 -arch >> i386 -o flac analyze.o decode.o encode.o

Hi, I'm trying to compile a static lib of libFLAC yet whenever I use it in an application, the application will fail on other machines because it's trying to use libogg.0.dylib. I'm using the following configure command ./configure prefix=${HOME}/libFLAC --disable-asm-optimizations --disable-dependency-tracking --with-ogg=${HOME}/libOGG --enable-shared=no but to do avail. Is there

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

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

lvqcl wrote: > Some projects/makefiles add both 'include' and 'include/share' > to the list of additional include directories. I think that is suboptimal. > For example, src/share/utf8/utf8.c includes 'include/share/alloc.h' > as "share/alloc.h" but 'include/share/utf8.h' as just "utf8.h". > > Also

I noticed that 32-bit flac (from git) compiled with GCC 4.8.3 or 4.9.0 calculates incorrect ReplayGain values. The most common value it produces is -55.17 dB. It is possible to avoid this bug by compiling src/share/replaygain_analysis/replaygain_analysis.c a) either without -msse2 option b) or with -O2 instead of -O3 c) another solution is to add -mfpmath=sse option along with -msse2. For GCC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tried to do this, gcc complained a lot about undefined references. After a bit of mucking with the code, i came up with a few patches. This might be a good conversation starter. The build that i've got out of this does pass the testsuite. To enable LTO you just need to apply these (for non-W32 builds you probably only need one of the patches)

On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:

The autoreconf tool is provided by autoconf to do what custom autogen.sh scripts in many projects used to do. Only it is more robust and widely tested. It has been available for several years, too. No reason to rely on custom code for this. Signed-off-by: Max Horn <max at quendi.de> --- Makefile.am | 2 - autogen.sh | 168

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`

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`