maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
I don't think it works. Unless I'm misreading things, once Camomile calls pd_init(), that call doesn't go to the pd_init that's compiled into Camomile (via libpd) but instead calls pd_init from the Pd that called vstplugin~ that called Camomile. This does nothing, and the next thing libpd tries to access in the Pd instance fails.
Maybe static linking of libpd in Camomile would fix this? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
