[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Re: Jack CVS error?

From: Josh Green
Subject: Re: [fluid-dev] Re: Jack CVS error?
Date: Thu, 09 Mar 2006 13:17:36 -0800

On Thu, 2006-03-09 at 21:38 +0100, Frank Barknecht wrote:
> Hallo,
> Josh Green hat gesagt: // Josh Green wrote:
> > On Thu, 2006-03-09 at 12:33 +0100, Frank Barknecht wrote:
> > > Well, I can do that, but won't I then also get a /usr/bin/fluidsynth
> > > binary without readline, ncurses and jack-support? 
> > 
> > Yep.  Not sure I understand what you are trying to achieve.  The nature
> > of using those libraries is that you end up with them as dependencies.
> > Some programs choose to build dependencies as modules, perhaps that is
> > what you are getting at?
> The background is, that some users of the fluid~ external, who
> compiled the external on their own, but used for example the
> libfluidsynth packages of their favourite Linux distribution, reported
> error messages similar to the one that started this thread, that is
> missing symbols located in libreadline or other libraries.
> These errors can be fixed by adding "-lreadline" when compiling
> fluid~, however fluid~ is not using readline, libjack etc. itself, as
> it is completely embedded in Pd or Max, so linking with any other
> library besides libfluidsynth normally is not necessary. 
> Another advantage could be that it reduces complexity when digging for
> bugs in applications, that use libfluidsynth. For example, if LADSPA
> is enabled in libfluidsynth, the fluid~ external will crash Pd. I
> reported this a long time ago, I'm not sure if it is fixed, but as
> LADSPA is not enabled as default anymore, this is no big deal
> currently.
> Moving things like LADSPA support out of the libfluidsynth library and
> have it only available in the fluidsynth application itself could make
> at least my life easier. ;) 
> I don't know how this would affact Rui and his QSynth, though. Of
> course it would affect the fluidsynth-application. :(
> Ciao

Ahh, I see what you are getting at now.  I don't quite understand why
fluid~ would have to be built with the same dependencies as the
libfluidsynth library though.  Shouldn't those dependencies get resolved
when fluid~ links to libfluidsynth?  Forgive my ignorance of how fluid~
works :)  The drivers are currently used by other applications such as
QSynth and Swami, so I don't see those dependencies going away for this
major revision of FluidSynth.  Perhaps there are some other solutions
        Best regards,
        Josh Green

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]