[PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)

Bryan Jurish jurish at ling.uni-potsdam.de
Wed Feb 7 12:36:16 CET 2007


moin Conor,

On 2007-02-07 01:12:05, Conor J Curran <forward at 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

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology




More information about the Pd-list mailing list