Displaying 20 results from an estimated 1000 matches similar to: "1.0 candidate"
2004 Sep 10
2
1.0 candidate checked in
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
2004 Sep 10
5
1.0 candidate checked in
On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote:
> Argh. Maybe libtool will have to get involved after all. I'll work on it
> this afternoon.
I think I give up. automake and libtool assume that the compiler will be able
to assemble stuff, and compilers don't generally understand NASM input. I
don't like the strip_fPIC bit, since just about anything that could
2004 Sep 10
2
1.0 candidate checked in
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 doesn't seem to recognize --tag=CC. What is its purpose?
>
> /bin/sh ../../../libtool --tag=CC --mode=compile \
> sh ../../../strip_fPIC.sh nasm -f
2004 Sep 10
2
1.0 candidate checked in
On Fri, Jul 20, 2001 at 04:17:38PM -0400, Matt Zimmerman wrote:
> Maybe the easy way to get around all of this is to build a plain old .a archive
> for the assembler stuff, instead of a libtool .la library. This may or may not
> cause problems when linking the libFLAC shared library. I'll try it.
It does work, but gives a warning:
*** Warning: Linking the shared library
2004 Sep 10
2
1.0 candidate checked in
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 doesn't seem to recognize --tag=CC. What is its purpose?
>
> /bin/sh ../../../libtool --tag=CC --mode=compile \
> sh ../../../strip_fPIC.sh nasm -f elf
2004 Sep 10
2
1.0 candidate checked in
> 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
2004 Sep 10
2
1.0 candidate checked in
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
2004 Sep 10
0
1.0 source candidate
On Fri, Jul 20, 2001 at 05:15:21PM -0700, Josh Coalson wrote:
> I rethought it and it seemed like a bad idea to post
> a big file, so you can get it here:
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2
With the attached patch, a complete "make distcheck" should work, including the
self-tests. It adds missing directories to some
2004 Sep 10
0
1.0 candidate checked in
--- Matt Zimmerman <mdz@debian.org> wrote:
> On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote:
>
> > Argh. Maybe libtool will have to get involved after all. I'll
> work on it
> > this afternoon.
>
> I think I give up. automake and libtool assume that the compiler
> will be able
> to assemble stuff, and compilers don't generally
2004 Sep 10
4
1.0 candidate checked in
I have checked in what should be the code for 1.0.
Unless I find some problems in the next two days
(I'm doing one more exhaustive test on another
100 CDs) the only thing that will be changing is
the new comparison table or maybe the configure
stuff.
So, last chance to checkout from CVS and break it!
Josh
P.S. Thanks to Andrey Astafiev, there's a Russian
translation of the docs, which
2004 Sep 10
3
patches for flac build
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
2004 Sep 10
2
1.0 candidate checked in
On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote:
> 2. Applied Matt's last cleanup patch of 8 files. I did not apply the patch
> to src/test_unit/main.c since it looks wrong. main.c is supposed to include
> the local bitbuffer.h, not src/libFLAC/private/bitbuffer.h; I think the
> current version is correct.
Ah, I missed that there was a local bitbuffer.h. In that
2004 Sep 10
5
1.0 source candidate
I rethought it and it seemed like a bad idea to post
a big file, so you can get it here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2
Josh
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
2012 Jan 01
1
Compiling 64-bit libFLAC/libFLAC++ on OS X Lion, anyone successful?
I have also asked this question on stackoverflow (http://stackoverflow.com/questions/8694676/compiling-64-bit-flac-libflac-in-os-x-lion), which you can answer if you're interested in reputation points.
I am very unfamiliar with compiling C/C++ source of this size, and I'm having trouble debugging the issue. Basically, in the root folder of the FLAC bundle, even if I use the flags
2012 Dec 03
4
[PATCH 1/5] Remove old GNU-stack sections from nasm files.
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
2004 Sep 10
5
Re: beta 10 candidate checked in
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
2004 Sep 10
2
1.0 candidate checked in
On Thu, Jul 19, 2001 at 02:56:11PM -0700, collver@linuxfreemail.com wrote:
> On Thu, Jul 19, 2001 at 05:01:07PM -0400, Matt Zimmerman wrote:
> > Once I removed that, it also seems to hate the .nasm extension:
> >
> > /bin/sh ../../../libtool --mode=compile \
> > sh ../../../strip_fPIC.sh nasm -f elf -d OBJ_FORMAT_elf cpu_asm.nasm
> > libtool: compile:
2004 Sep 10
2
Re: detecting host machine in configure.in?
--- 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
2006 Jul 27
1
[PATCH] nasm cleanup
Hi folks,
here's a patch which cleans up the nasm call from Makefiles.
Abusing libtool and then having to drop in some additional
wrapper script to rewrite the commandline again is rather stupid.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
2004 Sep 10
0
1.0 candidate checked in
On Thu, Jul 19, 2001 at 05:01:07PM -0400, Matt Zimmerman 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 doesn't seem to recognize --tag=CC. What is its purpose?
> >