[PD-dev] Re: [PD] trying to make devel_0_38

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jan 20 15:29:12 CET 2005


Tim Blechmann wrote:
>>i prefer i version of pd that compiles, installs and loads correctly 
>>even if it has some minor performance issues; i have never encountered
>>memory_locking bugs within pd myself (except for the famous hard
>>freeze of Gem when using "-rt" on linux; but this is a bug in nvidia's
>>drivers as i have found out)
> 
> well, unlikely, but possible ... see 
> man malloc
> man mlockall

yes, i did that.

it is just, that everything i have found on the web regarding this 
problem (hard freeze with an openGL application that uses page locking) 
was refering to nvidia's drivers.
redhat keeps closing this bug report, as "this is due to nvidia's 
drivers" (this is not a quote)

some tests have shown, that with pd/Gem it is really the memory-locking 
that kills pd (it goes up to 100% and becomes unkillable), and i guess 
the re-prioritizing makes this application lock a system lock.

the problem occurs when a glxWindow is created.

i really think it is an nvidia-driver problem (but of course i would be 
happy if not and the problem is solvable from here)


> 
>>no, i was rather referring to not finding the installed header files.
>>(and then it took me quite some time to find out where i had to add
>>the additional includes without re-running configure)
> 
> hm ... what exactly are you refering to? the only problem i'm aware of
> is the pd.tk path problem ...

compile-time problems.
when i tried to bootstrap.sh... pd would refuse to compile, because tk.h 
could not be found.
debian installs tk.h into /usr/include/tcl<X>.<Y>/

i had no problem at runtime (but i have not opened any property-box or 
whatsoever)


m,fg.as.dr
IOhannes




More information about the Pd-dev mailing list