similar to: XMMS plugin build fix

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 > +++

On Fri, Jul 20, 2001 at 01:06:53PM -0700, Josh Coalson wrote: > > xmmsinputplugin_LTLIBRARIES = libxmms-flac.la > > libxmms_flac_la_SOURCES = plugin.c > > -libxmms_flac_la_LIBADD = -L$(top_builddir)/src/libFLAC/.libs -lFLAC > > @XMMS_LIBS@ > > +libxmms_flac_la_LIBADD = @XMMS_LIBS@ > > $(top_builddir)/src/libFLAC/libFLAC.la > > libxmms_flac_la_LDFLAGS =

When linking against a libtool library, you should simply specify it on the libtool command line as you would a library or an object file. Nothing should ever reference the .libs directory directly. diff -u -r1.1.1.1 Makefile.am --- Makefile.am 2001/01/29 18:13:29 1.1.1.1 +++ Makefile.am 2001/06/14 20:13:20 @@ -9,5 +9,6 @@ xmmsinputplugin_LTLIBRARIES = libxmms-flac.la

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

Most of the programs don't use libogg or libm directly and should not link to them (overlinking). --- examples/c/decode/file/Makefile.am | 4 +--- src/flac/Makefile.am | 1 - src/metaflac/Makefile.am | 4 +--- src/plugin_xmms/Makefile.am | 1 - src/test_grabbag/cuesheet/Makefile.am | 4 +--- src/test_grabbag/picture/Makefile.am | 4

On Fri, Nov 08, 2002 at 12:39:52PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > I have few notes: > > > > It seems there is changed API in CVS again. So, what about adding > > function like > > unsigned FLAC__format_frame_size(const FLAC__Frame *frame) > > which returns size of the frame in bytes. This

On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > Yeah, it's useful, so now there is a > FLAC__seekable_stream_decoder_get_decode_position() and > FLAC__file_decoder_get_decode_position(). I haven't documented > them yet but you can see an example in > src/metaflac/operations_shorthand_seektable.c where I use it > during seektable creation. Ok, here is

--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > At 10:39 AM -0700 5/21/02, Josh Coalson wrote: > >--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > >> I guess the problem is really why is it trying to relink it? > >> > >> The "parse error: condition expected:" is suspicious, though.. > maybe > >> it's another "zsh as

--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > I guess the problem is really why is it trying to relink it? > > The "parse error: condition expected:" is suspicious, though.. maybe > it's another "zsh as sh" problem... hmm.. I don't remember having any trouble building the plugin on my ibook but that was a few months ago, so my memory may be fuzzy.

--- 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

Hi, And thanks for flac. There's a minor problem when compiling flac: libtool warns about mixing up shared and static libraries. Typical messages are: *** Warning: Linking the shared library libxmms-flac.la against the *** static library ../../src/plugin_common/libplugin_common.a is not portable! *** Warning: Linking the shared library libxmms-flac.la against the *** static library

Hi folks, here's a patch which adds an local xmms.m4 file (took it from latest stable xmms), so an complete autoconf regeneration also works if xmms is not installed. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit

Here is preliminary patch for fileinfo for xmms plugin. Saving and removing of the tag isn't working. When saving, how handle id3v1, v2? Display and edit more fields (e.g. performer)? How handle genres? Combo with predefined values? -- Miroslav Lichvar -------------- next part -------------- Index: src/plugin_xmms/Makefile.am

--- Matt Zimmerman <mdz@debian.org> wrote: > 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 > >

On Sat, Jul 21, 2001 at 03:53:26AM -0700, collver@linuxfreemail.com wrote: > > 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

> 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

Hi, Here's a patch to add support for streaming HTTP transport to the xmms plugin. Most of the code (in particular, http.c) is taken from the xmms mpg123 input plugin. You'll need to make a three-line change to the xmms mpg123 input plugin to get streaming to work. The mpeg plugin currently handles all http urls itself unless they end in an ogg or real audio extension (which means flac

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

Hi, I am doing my way on R, with much experimenting. So, I am trying to plot a 3d graphic ussing "persp" and entering a data set (attached) of UTM coordinates as x,y and a pH values as z. However when I try an error message comes out telling that increasing x and y values are expected. Jus ordering the first vector does not help, and, of course, order the first two independently

Hi, Below I've flagged some sentences in the R documentation (from cvs) which are garbled in some way. If anyone can clarify what these sentences should say I'd be grateful. The problems were picked up as part of the proof-reading of the R manuals by Ciaran O'Riordan. After looking at the text neither of us could figure out what the documentation was meant to say. -- Brian Gough