similar to: Compiling 64-bit libFLAC/libFLAC++ on OS X Lion, anyone successful?

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

Despite being documented as the place for submitting bug reports and patches, it seems like the sf.net bug tracker isn't get much attention, so here it is: http://sourceforge.net/p/flac/bugs/400/ During x86-windows builds using mingw or mingw-w64, nasm complains: nasm.h:83: warning: COFF section names limited to 8 characters: truncating I think the section .note.GNU-stack stuff aren't

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to

I just checked out the 1.0 candidate and ran autogen.sh autoconf errored out so autogen.sh did not work and I had to run automake manually. the autoconf error message was: configure.in:145: CFLAGS="$CFLAGS -fomit-frame-pointer -funroll-loops -finline-functions -Winline -DFLAC__INLINE=__inline__" anyhow I ran configure and I went into src/libFLAC/ia32 and ran gmake I get

lvqcl wrote: > Audacity still uses VS2008 and slowly tries to migrate to VS2012. > But as stated at <http://wiki.audacityteam.org/wiki/Developing_On_Windows>, > "Audacity is currently a 32-bit only application". So it doesn't need > 64-bit builds. > Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008 > and

1) Two comments ";ASSERT(lp_quantization <= 31)" in the new functions ..._wide_asm_ia32() -- just to mention this constraint. (max. possible value of lp_quantization is 15, so it's not a problem) 2) "mov cl, ..." was replaced with "mov ecx, ..." (again Agner Fog, optimizing_assembly.pdf) summary: write to a partial register may result in false dependencies

lvqcl wrote: > 1) > Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with > VC2005 Express and doesn't allow to build 64-bit files/libraries. > > IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio > 2012/2013 Express are free and allow to build 64-bit files. > > VS 2005/2008 use .vcproj files, and VS

hi, according to the FAQ flac supports multichannel formats. i had no luck with 1.1.4 though ( "Untitled.aif: ERROR: unsupported number channels 8 for AIFF" ), i guess that feature was added in 1.2? unfortunately, the binary for 1.2 does not run on OS X 10.4 (says libiconv is too old). i removed libiconv and reinstalled that from source, but then flac 1.2.1 just prints

On Wed, May 23, 2001 at 03:18:16PM -0700, Josh Coalson wrote: > but since I'm not too saavy with autoconf/automake I'll ask for a little bit > more help. I think the only non-functional part left is that automake > doesn't support source files that are in subdirectories, relative to > Makefile.am(?) the layout in src/libFLAC/ is that all asm sources will go > under a

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

I tried to compile FLAC on Windows (the winamp2 plugin as a test) and I encoutered a problem. The stat() function and the associated structure doesn't exist on Windows (Visual Studio 5/6). But _stat and the structure with the same name does exist. So would it be possible to change stat() and struct stat ? I did the following in the code : #define STAT(x,y) _stat(x,y) typedef struct stat

Hello, I am trying to compile some F77 subroutines as shared objects for R on my Mac. --> Mac OS-X Version 10.4.11 (Tiger Intel Mac) I have done this (successfully) before on Sun Solaris and Linux Fedora systems using the following command. > R CMD SHLIB myfile.f I have g77 installed from this page. http://hpc.sourceforge.net/ I am using R 2.8.1, and I have installed all 4 additional

Hello, I'm working with R, I try to call C from R. When I try to compile my file.c to make file.so, with the command : R CMD SHLIB foo.c return the message : gcc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -Wl,-macosx_version_min -Wl,10.4 -undefined dynamic_lookup -single_module -multiply_defined

On Thu, Jul 19, 2001 at 05:05:46PM -0700, Josh Coalson wrote: > --- collver@linuxfreemail.com wrote: > > On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > > > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > > > > > So, last chance to checkout from CVS and break it! > > > > > > Also, my libtool

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

Previously I wrote that precompute_partition_info_sums_32bit_asm_ia32_() only makes encoding slower. Now I managed to compile flac with GCC 4.8.1, with this function enabled and disabled. NASM was enabled, SSE intrinsics disabled. Then I added -msse option (so that all C code was compiled with -msse), then -msse2 and so on. Input file for test: 44.1kHz/16bit/stereo; best compression mode (flac

Hi all, It sees that the most serious bug in the flac bug tracker: https://sourceforge.net/p/flac/bugs/413/ has been fixed in git. This fix alone is worth a new release so its time to work towards one. Things I need to do for this new release: * Deal with all current patches on the mailing list. * Review all bugs reported against 1.3.0 on the sf.net. * Testing and coordination of testing

On Fri, Jul 20, 2001 at 03:01:54PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > > > automake will include ltmain.sh in the source distribution, so it > > should be > > used even if it isn't installed on the build system. In fact, it > > seems to > > always use the distributed version, and not the installed one

Hello, I recently built FLAC 0.10 in NetBSD 1.5 i386 and had to make minor changes to the build configuration. Thanks for the awesome software! libtool would not link the "plain" nasm-generated object files for the i386 assembly optimizations. I've patched src/libFLAC/i386/Makefile.am to operate similarly to the automake file used for the SDL assembly routines. I saw a post to

Erik de Castro Lopo <mle+la at mega-nerd.com> ?????(?) ? ????? ?????? Thu, 19 Jun 2014 17:01:26 +0400: >> (currently src/libFLAC/ia32 folder contains unused lpc_asm-unrolled.nasm >> file, so why remove unused bitreader_asm.nasm and stream_encoder_asm.nasm files?) > > I don't see any point in keeping files in release tarballs or in Git that > provide no value.