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$