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, Thomas