gr at grrrr.org
Sun Nov 13 23:58:04 CET 2005
>>>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
>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