Hola Bryan,
sounds familiar indeed... have you by any chance tried compiling your external without threads, linking (statically) to libflext-pd_s.a ? I don't know if you need threads or not, but at least that might narrow down the range of possible error sources...
I have not but I was under the impression that if I was to compile my external in the current flext setup using single-release. This would imply no use of threads and also statically linking to the .a lib as opposed to the .so. Is this correct? If not what do I need to do to ensure I do so? Sorry but I might have mentioned before I pretty clueless with this gcc stuff.
... I'd try it without FLEXT_THREADS (libpthread), both with and without FLEXT_USE_CMEM: that might make things clearer. I think this can be accomplished by:
(a) ensuring that FLEXT_THREADS is undefined for your external (-UFLEXT_THREADS)
Should -UFLEXT_THREADS be added to my config.txt in the external directory.
UFLAGS += -UFLEXT_THREADS ? Or should I ensure it is no defined. -U = undefine ?
(b) linking to the static single-threaded flext library, libflext-pd_s.a
... hmm, looking at it, it seems that the default shared libflext-pd.so is threadless, but is nonetheless compiled and linked with the -pthread option. Maybe it might help to remove the "-pthread" compiler & linker flags for threadless (shared,single) builds: this amounts to editing flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the dark, but at least it would make debugging easier ;-)
I have edited this file so now the part which did contain the pthread stuff looks like this ############################################## #removed from both: -pthread CFLAGS += -fPIC LDFLAGS += -shared
One question are you working from 5.0 release of flext or are you using the head of cvs?
I will have some more time to spend on this tomorrow evening.
until the morning.
Cj
marmosets, Bryan