[PD-dev] compiling pd_devel_0.38 on sarge

[IOhannes m zmoelnig]

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