Mmmm I wouldn't make this assumption. By default, the libpd repo makefile throws in LIBDL when linking on platforms that support it, so desktop apps *could* support loading externals. I for one, however, have not relied on this myself, but I could imagine *someone, somewhere* does?

On Apr 4, 2022, at 3:01 PM, pd-dev-request@lists.iem.at wrote:

Message: 2 Date: Mon, 4 Apr 2022 15:00:52 +0200 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension) Message-ID: <0861a01f-14da-166c-df62-d8cebe2ed823@christofressi.com mailto:0861a01f-14da-166c-df62-d8cebe2ed823@christofressi.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"

...

I was thinking to a way for the transition: we could:

• change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*

replacement? macros accordingly),

• export "hidden" globals s_*
• initialize pd_maininstance pd_s_* fields to the global versions.

Yes, this would work. Of course, it would be an ABI break for multi-instance libpd, but I think it would be justified. I guess libpd users rarely rely on pre-build externals, and even if they do, I think it's ok to ask them to recompile.

-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/