[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Jack Driver for Fluidsynth Windows Build
From: |
David Henningsson |
Subject: |
Re: [fluid-dev] Jack Driver for Fluidsynth Windows Build |
Date: |
Mon, 18 Apr 2011 11:38:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110411 Thunderbird/3.1.9 |
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.
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. I'm not sure how this relates to ASIO though, it seems
like an unrelated problem...?
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.
</I'm-not-a-lawyer disclaimer>
// David