On Jan 4, 2017, at 4:00 AM, pd-list-request@lists.iem.at wrote:

the important question is of course, whether the various language
wrappers would be able to use a common libpd.so - if not, the entire
exercise might be moot.

On platforms with dynamic linking (*nix, non-iOS), this should be no problem.

afaict, the wrappers currently use static linking, but that might just
be for convenience reasons.

Yes. I want to add building dynamic libs but thought to do so with a move to autotools.

it would be interesting to hear peter and dan (or some other libpd
experts) on this.

I see two options:

1. Have the pd core, as required by libpd, built as a separate dynamic lib. We could do this with the recent autotools updates relatively easily. Then vanilla as well as libpd and it's wrappers all link to the same lib. Downside is you’re required to install the puredata package to use libpd. This then brings up the idea of could the core be it’s own separate package that the others all use? This leads to option 2.

2. The pd core is split out as a separate library which the gui and the libpd wrappers all use. At that point, it’s basically libpd. Downside here of course is figuring out what makes the most sense in regards to future development (ie. is this desired?) and plainly doing the work. This is probably the best overall approach going forward and was touched upon by some of the discussions at the pd con, but I might be afraid of “breaking things that work.” :)

on the long run, i'm dreaming of pd-vanilla using libpd directly (that
is, dynamically linking against libpd.so like other applications, rather
than statically including it). but that's probably for 0.48-1 :-)