Tim Blechmann wrote:
pd binary ... possibly to the wrong one ...
sorry, can't answer with a zexy example, since the symbols are stripped ... but i'd suggest to run "nm zexy.pd_linux | grep U" to see the undefined symbols ... most of them are exported from the pd binary: U atom_string U binbuf_add U binbuf_addbinbuf U binbuf_addsemi U binbuf_addv U binbuf_clear
these symbols are resolved at runtime ... if you'd like to use zexy in an application not providing these symbols, you'll get some undefined symbol messages ... if these symbols are resolved in the wrong way, anything can happen ;-)
yes of course. but the external does not go and load another library to resolve these symbols but the parent application (whichever pd) has to provide them. so imo the 2 pd's cannot interfere in that way. if an application provides "atom_string" (either because it defines them itself or it imports a dynamic library that provides them _prior_ to opening the external) then zexy can use them no matter what other binaries are installed on the machine. if an application does not provide those symbols, then loading an external that depends on them will miserably fail, but you'll get an error about undefined symbols (and which ones) i have experienced this a lot :-)
the only thing that does not work without magic, is that an external depends on external symbols but does not explicitely define where to look for them (via linking against those dynamically!) and those symbols are not defined by pd (or a library that has been loaded _beforehand_). it will definitely not start to search random libraries (like pd-stable) installed on your harddisk.
mfg.ad.sr IOhannes