moin Conor,
On 2007-02-07 01:12:05, Conor J Curran forward@forwind.net appears to have written:
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.
yep, afaik any -single build should produce a threadless (the official term in Thomas' documentation appears to be "single-threaded") version; at least, the flext build system won't define FLEXT_THREADS for *-single builds. Just make sure you're not defining it yourself ;-)
... 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 ?
If you're not defining it (e.g. with -DFLEXT_THREADS or with a #define in some source file), then you're ok: it won't be defined by flext build.sh for a *-single build.
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
yep, that's the bit I meant. As I noted yesterday, my fluid~ problems were due to a missing initialization / assumed zero-initialization of the object's memory, which resulted in an attempt to free() a pointer of basically random junk (either unallocated or allocated by a different program or thread or whatever)...
According to the gcc docs:
-pthread Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags.
... there are -pthread flags listed for other architectures too, and gcc doesn't complain about the flags, but I haven't yet found any docs for the -pthread option on x86, so maybe it doesn't do anything at all here except maybe link to libpthread...
One question are you working from 5.0 release of flext or are you using the head of cvs?
I'm using the head of cvs, and I haven't actually removed the "-pthread" from my build flags here. Of course, I am still getting bizarre crashes & lockups, but not the fluid~-related ones.
marmosets, Bryan