Em sex., 20 de mar. de 2026 às 19:24, Christof Ressi <[email protected]> escreveu:
> On 3/20/2026 11:12 PM, Alexandre Torres Porres wrote: > > Thanks for the guidance Christof. I added -Wl,-export_dynamic to my > plugin's LDFLAGS, but _pd_this still isn't exported. nm -gU plugin.dylib > shows: > > text > 0000000000115be0 S _pd_this > > As I understand, it's a thread‑local symbol (S), not a global data symbol > (D). It seems that on macOS thread‑local symbols are not exported to the > dynamic linker, is that correct? > > Actually, that is the case on Windows, so I have added the following > workaround: > > > https://github.com/pure-data/pure-data/blob/208fd75ec24d381dddada34224dc40ee1ed73238/src/m_pd.h#L1070-L1078 > > If this is also true on macOS > Well, all I know and can affirm is that *nm -gU plugin.dylib* shows *_pd_this* as *S* (section symbol), not *D* or *T*. :) I can try and test your workaround, but then, I fear I might still face those consistency check errors, since they also appear and resolving the issues with static linking didn't help. Let me check and report back. thanks > , try to apply the same workaround (by replacing #ifdef _WIN32 with #if > defined(_WIN32) || defined(__APPLE__)) and see if that fixes the issue! > > Are the other symbols all exported correctly? > > > This is what I get trying to run the patch loading externals dynamically... > > libpd: verbose(0): impseq~ 1 0.5 0.25 0 > > > libpd: error: ... couldn't create > > > libpd: error: /Users/alexandreporres/Library/Application > Support/Rack2/plugins-mac-arm64/PureData/patches/else/adsr~.darwin-arm64-32.so:dlopen(/Users/alexandreporres/Library/Application > Support/Rack2/plugins-mac-arm64/PureData/patches/else/adsr~.darwin-arm64-32.so, > 0x000A): symbol not found in flat namespace '_nullfn' > > > > I also get a bunch of > > libpd: error: consistency check failed: signal_new > > If what I say is true, it seems dynamic loading of multi‑instance > externals is impossible on macOS. Do you know of any workaround besides > static linking? PlugData uses static linking, but I was hoping to avoid > that as this seemed easier. But I spent all day trying to statically link > and in fact I got rid of these symbol warnings, but I am still getting a > bunch of "*libpd: error: consistency check failed: signal_new*", so I > guess I was successful and I still have this other issue to overcome and I > simply have no idea of what that might be :) > > Thanks, > Alex > > Em sex., 20 de mar. de 2026 às 18:41, Christof Ressi < > [email protected]> escreveu: > >> Hi, >> >> So I added -Wl,-export_dynamic to libpd build and plugin LDFLAGS. Result: >> same _pd_this and _nullfn errors persist. >> >> In your VCV plugin you are using libpd as a static library (libpd.a). The >> -export_dynamic option must be passed to the VCV plugin because linker >> flags do not apply to static libraries (which are just collections of >> object files), they apply to executables and shared libraries. >> >> Once you have built the VCV plugin, you can use "nm" to check which >> symbols are actually exported. If _pd_this is not exported, externals won't >> load (unless they have been statically linked and loaded manually). >> >> BTW, I noticed something in the Makefile ( >> https://github.com/porres/VCV-PureData/blob/main/Makefile): >> >> # Also force heap allocation path to avoid missing alloca.h in some MinGW >> toolchains. >> >> -DDONT_USE_ALLOCA=1' >> >> Don't do that! I've never had a problem with alloca.h on MinGW. Forcing >> heap allocation for small temporary allocations is BAD. >> >> Christof >> On 3/20/2026 6:18 PM, Alexandre Torres Porres wrote: >> >> Hi, I’m working on a VCV Rack module that runs Pd via libpd and I wanna >> add ELSE externals. This is a desktop application for those unaware. >> >> >> I Stripped down the original Prototype module to Pd-only, Pd support was >> added by CHAIR (Max Neupert and Clemens), then I Ported to VCV Rack 2 API, >> built libpd with multi-instance support and enabled having many modules >> running Pd. It successfully loads Pd patches, audio I/O works, >> knobs/switches/lights work at least with one of the examples, I’m diving >> into it. Check https://github.com/porres/VCV-PureData >> >> >> ELSE builds fine in PlugData via pdlib but Tim told me that’s tricky and >> that I could start by simply using [declare] and using externals just like >> in the regular Pd, but that’s not working… I first got errors like symbol >> not found: _s_list and _nullfn. >> >> >> So I did some research and recompiled ELSE with -DPDINSTANCE to match my >> multi-instance libpd as it seemed needed. Result: error changed to symbol >> not found: _pd_this and still _nullfn. The binaries did not work as well on >> the regular Pd app on my desktop. >> >> >> So I added -Wl,-export_dynamic to libpd build and plugin LDFLAGS. Result: >> same _pd_this and _nullfn errors persist. >> >> >> Can anyone shed me some light on this? This is the first time ever I am >> trying to work with libpd myself… >> >> >> >> Would static linking (like PlugData does, which is notably harder) the >> only reliable approach for me? If so, why? >> >> >> thanks in advance >> >> cheers >> >> [email protected] - the Pd developers' >> mailinglisthttps://lists.iem.at/hyperkitty/list/[email protected]/message/OIR3J3H32G7NL4LUCYPK5WKLZAZS6A3S/ >> >> --- >> [email protected] - the Pd developers' mailinglist >> >> https://lists.iem.at/hyperkitty/list/[email protected]/message/W63QZ2DHFBB2FPZBX6NZNTHV4GO4RQ6N/ > >
--- [email protected] - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/LXBGMIYPCOF6ZQTLMW4N53Y3IER3ANZX/
