Re: [fluid-dev] Jack Driver for Fluidsynth Windows Build

[Stéphane Letz]

Le 18 avr. 2011 à 11:38, David Henningsson a écrit :

> On 2011-04-18 10:35, Stéphane Letz wrote:
>> 
>> Le 18 avr. 2011 à 08:47, David Henningsson a écrit :
>> 
>>> Hi Graham,
>>> 
>>> I don't want to push the problem back and forward, but in this case I think 
>>> it's reasonable to say that:
>>> 
>>> 1) We need to be told by the Jack devs about recommended way to link to the 
>>> jack headers.
>>> Does that means dynamic linking?
>> 
>> I guess you mean "weak linking" right? (that is the fact that fluidsynth can 
>> start even if libjack is not found...)
> 
> Dynamic linking is when you look up the function at runtime (using 
> LoadLibrary / GetProcAddress in windows), vs static linking where that is 
> done by the loader before the program starts. Weak linking is a new concept 
> for me and I haven't fully understood it yet.

OK, we actually agree ((-:
> 
>>> On windows only or on all platforms? Will that still work with e g Jack 1? 
>>> Anyway, if we conclude dynamic linking is the way forward, it is reasonable 
>>> to think that there should be a version of JackWeakAPI.cpp that is in C and 
>>> not C++ (just like the rest of FS).
>>> I don't exactly know how difficult it would be to bring C++ code into FS on 
>>> all platforms, but it would probably be more difficult than rewriting 
>>> JackWeakAPI.cpp in pure C.
>>> 
>> 
>> Well I think the code in JackWeakAPI.cpp is completely C.... so the file can 
>> probably be safely used in C. I'll check again.
>> 
>> Concerning weak linking itself: the thing is that on jack now use (or tries 
>> to use...) __attribute__((__weak__)) kind of stuff from GCC, see:
>> 
>> http://trac.jackaudio.org/browser/jack2/trunk/jackmp/common/jack/weakjack.h
>> 
>> but the problem is that  I could not make this work on Windows which uses  
>> __declspec(dllexport) stuff to export symbols from the DLL. So on Windows 
>> the "compile JackWeakAPI.cpp" is the way to go. On OSX or Linux the more 
>> standard way (describe in weakjack.h) can be used.
> 
> Ok, I don't mind compiling in JackWeakAPI.c into FluidSynth for the Windows 
> build.

OK.

> I'm not sure how this relates to ASIO though, it seems like an unrelated 
> problem...?

Completely unrelated. If fluidsynth uses the JACK API directly, then ASIO 
bridge (JackRouter) is out the picture.

The point of using JACK API directly is to remove "using JackRouter would open 
*only one* ASIO driver thus only one JACK client" limitation....


> 
>>> 2) If Jack has an ASIO backend, that's great news! However, looking at
>>> http://trac.jackaudio.org/browser/jack2/trunk/jackmp/windows/JackRouter/JackRouter.h
>>> it seems to be declared under GPLv2+. I don't see how the end result could 
>>> be legally distributed in binary form, when the ASIO headers cannot be 
>>> freely distributed.
>>> 
>> OK, but the ASIO headers  are only included to compile JackRouter. What 
>> would be the appropriate licence to be able to distribute binaries of 
>> JackRouter?
> 
> <I'm-not-a-lawyer disclaimer>
> 
> As I understand it the library closest to ASIO, i e the library that actually 
> needs the ASIO headers to compile, needs to be something very permissive, e g 
> BSD.
> 
> The rest of the libraries that are linked in, e g FluidSynth, can be LGPL. 
> GPL is problematic at all layers.

Ok, 'ill mode to a more permissive license then for JackRouter code.

Stéphane