That's right - my mistake. OTOH externs that use &s_, etc., won't be
binary compatible and will need recompiling or fixing to avoid those
symbols. This is probably less concerning than in the case of VST
plug-ins where users might not have a compiler handy.
So I think I should just provide s_, etc., for VST plug-ins and no more
broadly than that - other people making end-user apps with libpd can
always do the same.
Meanwhile, c-language symbol clashes are still a problem. I've thought
of a way one could edit, recompile and package externs so that they try
first to bind to pd_class_new() and then failing that go back to
class_new()... but the easier path is probably for me to release a pd
vanilla 0.55-3 that provides the new symbols, so that it's at least
possible to make an extern whose binary works in "stable" Pd but also in
VSTs, and that won't need recompiling or repackaging for future Pds.
cheers
Miller
On 4/4/25 10:28 PM, Dan Wilcox wrote:
This already works for desktop libpd projects as long as libdl is linked.
On Apr 4, 2025, at 8:41 PM, Miller Puckette via Pd-dev
<pd-dev@lists.iem.at> wrote:
My longer-term hope is to be able to load externs dynamically into
either Pd or libpd without having to compile separately for the two
situations...
--------
Dan Wilcox
danomatika.com
<https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwOp0BXIw$>
robotcowboy.com
<https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwHBNrcb6$>
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/ASYIXH6BXXJAF5PFOTWEEZFAQCNUNLJR/
