[PD] rradical

Thomas Grill gr at grrrr.org
Sun Nov 13 23:58:04 CET 2005

Hi Frank,

>>>hm, that gdb output somehow looks similar to a crash, people were
>>>experiencing with loading xsample and pool at the same time. You could
>>>try to move fluid~.pd_linux somewhere, where Pd cannot see it and
>>>check, if it still crashes. 
>>hmmm, seems like at times i'll have to figure out how to make things 
>>really user-proof.
>Is this somehow related to the FLEXT_GLOBAL_NEW (or similar) define?
>Should I maybe undef this in the fluid~-source or build system? 
the bad thing on linux seems to be that one function symbol (like the 
global operator new in this case) must be unique in a process, or, if 
there are different versions, it's not forseeable (for me) which one is 
taken. In this sense FLEXT_NOGLOBAL_NEW needs to be defined for both the 
flext build and the external, or not be defined for both.
It seems like, to avoid this problems in the future, the best thing 
would be to simply ignore the PD memory reservation scheme (getbytes) 
and (for linux at least) assume FLEXT_NOGLOBAL_NEW generally, because 
getbytes simply maps to the C standard library anyway.

On the other hand all problems i lately inspected on user's machines 
have been due to misconfigured flext/buildsys/config-pd-linux-gcc.txt 
files or old versions of some headers and/or libraries or due to old 
versions in general, or combinations of the above.

Please tell me your solution, once it's working

all the best,

More information about the Pd-list mailing list