similar to: libtool "missing sed" bug

finished hooking up the altivec stuff so it works in ProjectBuilder. I ran a test, doing a 'flac -t' on 400MB of files compresses at level 5. the runtime dropped from from 180 sec to 105 sec! once I get the latest autotools on my ibook I'll try and get asm compilation to work that way. Josh --- Josh Coalson <xflac@yahoo.com> wrote: > OK, checked it all in (only minor

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

On Fri, Jul 20, 2001 at 02:42:21PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > It does work, but gives a warning: > > > > *** Warning: Linking the shared library libFLAC.la against the *** static > > library ia32/libFLAC-asm.a is not portable! > > > > I think this is just because libtool can't determine whether the

All, I have just finished uploading the source release for FLAC 1.0.4 beta to Sourceforge; there are no binary releases. See the included doc/html/news.html for the changes since 1.0.3; there are quite a few. http://prdownloads.sourceforge.net/flac/flac-1.0.4_beta-src.tar.gz?download Please beat up on this as much as possible in the next week or two and try and turn up bugs. Here's a

--- Matt Zimmerman <mdz@debian.org> wrote: > The only difference in the command lines seems to be that your > xmms-config > explicitly links with -lgthread, while I suppose mine lets the > dynamic linker > pull it in. The only significant difference between the old and new > _LIBADD > lines is that @XMMS_LIBS@ is at the beginning in the new one. Now > that I think

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179434 In order to fix this for Debian, I changed things around to build the .a libraries as libtool convenience libraries; this takes care of PIC and they can be portably linked into shared libraries (I believe libtool would complain about this otherwise). Josh, how would you feel about me merging these changes into flac CVS? -- - mdz

I've encountered a new problem building gluster-2.0.1 that I did not have with gluster-2.0.0rc8. This is on a mandriva-2008.1-x86_64 system. ../../libtool: line 466: CDPATH: command not found ../../libtool: line 1144: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from an older

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

RHEL5 has autoconf 2.59 and automake 1.9.6. I've managed to build the whole Xapian family by reducing the requirement to 2.59/1.9.6 in configure.ac. Omega requires docdir which can be added by hand in docs/Makefile.am: docdir = ${datadir}/doc/${PACKAGE} if !MAINTAINER_NO_DOCS dist_doc_DATA = $(RSTHTML) endif All I've done is get these packages compiled - I haven't tested in any

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/

--- Matt Zimmerman <mdz@debian.org> wrote: > I did not catch the beginning of this thread. What is the bug? > yeah, the thread's about a month old. you can see the whole thing here: http://sourceforge.net/mailarchive/forum.php?thread_id=738315&forum_id=6312 basically on OS X Ben's libtool is trying to "relink" libxmms-flac with the installed libFLAC before

after spending a lot of time integrating X-Fixer's winamp2 plugin code, I am on the verge of removing id3 v1/v2 support from the plugins completely. it is really hard to get right in a way that works intuitively for the user, and i18n is also a nightmare. in id3v2 every field can have a different encoding. FLAC tag a.k.a. Vorbis comment support is very good now so unless someone comes up

Thanks. I was worried about the assembler invocation but it looks like you solved that problem. Smooth build on my pbook (G4, 10.2.8, gcc-3.3, ac-2.59, am-1.6.3). Only problem was lack of check for docbook-to-man; my patch is attachments 1-2. Not so smooth on my imac (G3, 10.2.8, gcc-3.3, ac-2.52, am-1.6.1; that's what came with the last 10.2-compatible dev tools). First problem: typo 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

Damn, back to this thread: > I think I sent a bad patch for this one already, which used a _LIBS > variable. > There is no _LIBS variable. :-) So, the .la file should be specified > directly > in _LIBADD, with no linker flag syntax. libtool will figure it out. > > diff -u -r1.1.1.1 Makefile.am > --- Makefile.am 29 Jan 2001 18:13:29 -0000 1.1.1.1 > +++

It looks like libplugin_common.a is being linked into the shared object libxmms-flac.so. In that case, all of the objects in libplugin_common.a must be compiled with -fPIC. ----- Forwarded message from lamont+buildd@hp.com ----- Date: Sat, 28 Sep 2002 18:54:08 -0600 From: lamont+buildd@hp.com Resent-From: lamont+buildd@hp.com To: submit@bugs.debian.org Subject: Bug#162718:

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

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

Hello, I can compile metadata plugin using debian squeeze + wheezy. But build on suse enterprise server 9,10 and 11 failed. The metadata plugin require autoconf-2.65 which i too new. On the other side I can build the dovecot-2.2.4 and pigeonhole-0.4.0 plugin without problems: dovecot require autoconf-2.59 and pigeonhole does not require any specific autoconf version. I asked the authors of the

hello all, i'm new to xapian and am just beginning to play around with the python bindings. first off, the example (simplesearch.py) i pulled from cvs didn't work complaining of not finding the _xapian module. after using strace, i noticed python trying to search for _xapian.so. the default xapian-bindings build produces _xapian (without the .so extension) so renaming it to _xapian.so