fftw, licencing, linking.

[kanashimia]

Hello @falkTX, you said before that vitalium can't directly (statically?) link to fftw3, because of the licencing incompatibilities with juce, but is that really the case?
Both JUCE and FFTW can be under GPLv3 here as i see?

I can see how there could be problems for original vital, but because vitalium has all of the code available, and doesn't even have binary releases, and you don't sell them, there shouldn't be any problems?

Right now i am not sure how to package this without patching elf file? Also patching it would defeat the whole purpose of using dlopen anyways - may as well just link it from the beginning.
Figuring out if it /actually/ finds the lib isn't fun, static linking would save alot of trouble.

Also need to figure out what is the licencing of this repo overall.

Thanks for reading.

[falkTX]

Good question.
If the juce plugin is GPL, there is no license incompatibility. juce prefers to use dlopen because it targets commercial plugins.
so you are right that we do not need to care about this.

have a look at https://github.com/DISTRHO/DISTRHO-Ports/blob/master/libs/juce-current/AppConfig.h#L312
try building while setting that to 1. then we need to remove the partial-dep stuff from fftw meson dependency on https://github.com/DISTRHO/DISTRHO-Ports/blob/master/meson.build#L81

btw, note that on juce6 (so vitalium and swankyamp plugins) all of X11 stuff is used by dlopen methods.

[kanashimia]

Tried with:

diff --git a/libs/juce-current/AppConfig.h b/libs/juce-current/AppConfig.h
index 111604d6..c20d514c 100755
--- a/libs/juce-current/AppConfig.h
+++ b/libs/juce-current/AppConfig.h
@@ -307,7 +307,7 @@

     You must respect the FFTW license when enabling this option.
 */
-#define JUCE_DSP_USE_SHARED_FFTW 1
+#define JUCE_DSP_USE_SHARED_FFTW 0^M

 /** Config: JUCE_DSP_USE_STATIC_FFTW

@@ -320,7 +320,7 @@

     You must respect the FFTW license when enabling this option.
 */
-#define JUCE_DSP_USE_STATIC_FFTW 0
+#define JUCE_DSP_USE_STATIC_FFTW 1^M

 /** Config: JUCE_DSP_ENABLE_SNAP_TO_ZERO

diff --git a/meson.build b/meson.build
index 215df76f..7d4184af 100644
--- a/meson.build
+++ b/meson.build
@@ -78,7 +78,7 @@ if os_linux
     dependencies = [
         cc.find_library('dl'),
         cc.find_library('rt'),
-        dependency('fftw3f').partial_dependency(link_args: false, links: false),
+        cc.find_library('fftw3f'),
     ]
     dependencies_devices = [
         dependency('alsa'),

Btw idk why diff prints ^M there, and only in the added lines - they both have same line endings looking through cat -e

›ldd vitalium.so
        ...
	libfftw3f.so.3 => /nix/store/k4la012nqx1fql8wik7rvxd57r6zjn4s-fftw-single-3.3.9/lib/libfftw3f.so.3 (0x00007f1a12858000)
        ...

But yeah seems to work, DEBUGGER="ltrace -l libfftw3f.so.3" ardour6 confirms it.
It doesn't require headers to be there, not entirely sure why is that option named "static".

[falkTX]

juce calls that static because their build system expects it. we use a custom meson setup, so doesnt apply to us.
would you mind creating a PR with these changes? otherwise I do it myself later on.

[falkTX]

actually, dont do a PR. I do not want fftwf as dependency on all plugins. I will figure out a proper solution later, let me create a ticket for this now

[kanashimia]

So anyways, JUCE 6 is GPLv3 only, but i see there are GPLv2+ and LGPLv3+ in the doc directory of this repo.
So if i want to package this whole collection, redistribute, i would need to follow GPLv3 conditions?
Can you qualify licensing in the README.md or LICENCE file.

[falkTX]

right, so juce used to be gplv2 some years ago, then changed to gplv3.
we need to replace the gplv2 with gplv3 license in those files.

not all plugins are made with gplv3 license though, most old ones are gplv2 that get updated to gplv3 due to v2+ clause