Hi all,
I'm working on a plugin that dynamically loads PD patches. Everything works fine, I even manage the multiple instances issue. You can take a look at it if you want : https://github.com/pierreguillot/Camomile. My problem is that the plugin can't load dynamically the external libraries (I tried with freeverb~ and other libraries and I got : Symbol not found: _s_signal Referenced from: /Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin Expected in: flat namespace). I don't have any linker flag and I set up this set of macros for the preprocessor: PD=1 HAVE_UNISTD_H=1 USEAPI_DUMMY=1 HAVE_ALLOCA_H=1 HAVE_LIBDL=1 PD_INTERNAL=1 I use Xcode 7.2.1 with LLVM and OSX 10.9 for the deployment target (required for c++11 support). I going to try on Linux but if anybody has a clue for Mac I would be grateful (I must use Xcode because it's a JUCE project).
Cheers
On 03/09/2016 09:54 PM, Pierre Guillot wrote:
I'm working on a plugin that dynamically loads PD patches. Everything works fine, I even manage the multiple instances issue. You can take a look at it if you want : https://github.com/pierreguillot/Camomile. My problem is that the plugin can't load dynamically the external libraries (I tried with freeverb~ and other libraries and I got : Symbol not found: _s_signal
so what is the Pd-engine you use? is it loaded before trying to load the external?
I compile Pure Data sources with my plugin, I use the GitHub Pure Data repository (https://github.com/pure-data/pure-data). I think the symbol is well exported :
nm camomile | grep s_signal 0000000000699a60 D _s_signal 000000000010c0c0 t _sys_signal
but I forget to give you the full error : tried /Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin and succeeded verbose(4): /Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin: dlopen(/Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin, 10): Symbol not found: _s_signal Referenced from: /Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin Expected in: dynamic lookup
2016-03-10 0:17 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/09/2016 09:54 PM, Pierre Guillot wrote:
I'm working on a plugin that dynamically loads PD patches. Everything
works
fine, I even manage the multiple instances issue. You can take a look at
it
if you want : https://github.com/pierreguillot/Camomile. My problem is
that
the plugin can't load dynamically the external libraries (I tried with freeverb~ and other libraries and I got : Symbol not found: _s_signal
so what is the Pd-engine you use? is it loaded before trying to load the external?
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, Mar 9, 2016 at 9:54 PM, Pierre Guillot guillotpierre6@gmail.com wrote:
Hi all,
I'm working on a plugin that dynamically loads PD patches. Everything works fine, I even manage the multiple instances issue. You can take a look at it if you want : https://github.com/pierreguillot/Camomile. My problem is that the plugin can't load dynamically the external libraries (I tried with freeverb~ and other libraries and I got : Symbol not found: _s_signal Referenced from: /Users/Pierre/GitHub/Camomile/Patches/freeverb~.pd_darwin Expected in: flat namespace). I don't have any linker flag and I set up this set of macros for the preprocessor: PD=1 HAVE_UNISTD_H=1 USEAPI_DUMMY=1 HAVE_ALLOCA_H=1 HAVE_LIBDL=1 PD_INTERNAL=1 I use Xcode 7.2.1 with LLVM and OSX 10.9 for the deployment target (required for c++11 support). I going to try on Linux but if anybody has a clue for Mac I would be grateful (I must use Xcode because it's a JUCE project).
libpds has the same problem. If I remember correctly, the problem is that you have to link your plugin with RTLD_GLOBAL in order for your externals to see the symbols, but you don't control how the host loads your plugin. But even if you could (and you probably can if you make a wrapper plugin that loads your actual plugin), it wouldn't work very well since you would get lots of symbol clash when trying to load a second instance of your plugin.
So what I did in libpds was to statically link all externals (in pd extended) into libpds [1]. Of course, that's not exactly a perfect solution, but it's a lot better than not being able to use any external.
Maybe it's possible to create your own linker system that somehow fixes it though, I don't know.
[1] https://github.com/kmatheussen/libpd/blob/master/make.scm
On Thu, Mar 10, 2016 at 9:45 AM, Kjetil Matheussen <k.s.matheussen@gmail.com
wrote:
is that you have to link your plugin with RTLD_GLOBAL in order for your externals to see the symbols, but you don't control how the host loads your plugin. But even if you could (and you probably can if you make a wrapper plugin that loads your actual plugin), it wouldn't work very well since you would get lots of symbol clash when trying to load a second instance of your plugin.
Oops, my mind was stuck a little bit in the past when I wrote this. When I wrote libpds there weren't any support for several dsp graphs, which I guess you are using to get multiple instances (?). In that case, it might work to create a wrapper plugin (as I suggested), and load your actual plugin once with RTLD_GLOBAL, but only if it hadn't already been loaded. I've been meaning to do this for libpds for a very long time now, but it's been so much other things to do.
Does it means that if the host opens the plug-in with RTLD_LOCAL flag, that plug-in will not be able to export its symbols table to its own dlopened externals (even doing it with RTLD_GLOBAL)?
-
IOhannes m zmölnig -
Kjetil Matheussen -
Nicolas Danet -
Pierre Guillot