In the case of Ableton, it might be that Pd's extern functions are clashing with Max's coming from Max4Live. I thought there was a linker flag, at least on Windows, in order to deal with this that puts linked libs into a sort of different space, however that probably doesn't help in the case of externs trying to find the class functions.
Overall, I think prepending all such functions into a general "pd_" naming is the easiest and most correct long term solution, with fallback to classic naming. As established by Peter K, libpd took this route for all public functions. Even for such a storied project, it's cool to see Pd still has "growing pains" and is indicative that we still have new and interesting spaces to grow into ala "pd anywhere." ;) I would suggest doing this with a Pd 0.56 release since IMO it would be the beginning of a major API change, even if such a release is really only bug fixes + this. IN the future, it would be easier to mark where this change came to know which precompile externs would still work and which not. Another option, for compatibility, would be a completive define which exposes the original API after a hard transition is made. > On Apr 5, 2025, at 11:54 AM, Miller Puckette <mpucke...@ucsd.edu> wrote: > > 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$> >> > -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/N6GLWXRMF26NPQDEJA2TGVP3QEAF5CPV/
