[Gridflow-dev] segmentation faults with pd-0.39-test6

[Mathieu Bouchard]

On Wed, 24 Aug 2005, Claude Heiland-Allen wrote:
> claude at minimus ~/Build/Pd/Gridflow/GFcvs $ equery which ruby
> /usr/portage/dev-lang/ruby/ruby-1.8.3_pre1.ebuild
> > If it doesn't work, I'd try Ruby 1.9.0. Compile it yourself, with
> > ./configure --enable-shared. You may first remove any trace of Ruby on
> > your system to avoid confusion, or else make sure you always know
> > which Ruby is running. NOTE: you then have to
> > reconf+recompile+reinstall GF.
> Ok, I will now remove Ruby from my system and install Ruby 1.9.0, then try
> again.

<ClaudiusMinimus> ok, just finished compiling, ./configure can't find
ruby, so i'm about to make a link to ruby19

<ClaudiusMinimus> matju: config.h has #define STACK_END "0xbf9d6ffc",
going to leave that as-is and make && make install

<ClaudiusMinimus> matju: well, so far so good - pd started first time 
without crashing, STACK_END old=0xbfcf6ffc; new=0xbfcffffc

Ruby 1.9 ignores all the STACK_END stuff, as it finally figures it out by 
itself like a grown-up.

However, the fact that 0xbffffffc didn't work with 1.8 seems to indicate 
that something else was wrong. Is it possible that Ruby 1.8 got compiled 
using -O3 optimisations?... Because some parts of Ruby don't really like 
it (nor take it).

Also you should be extra careful about not loading an older
gridflow.pd_linux that might be in another dir that has higher priority in
the path. That's always a killer.

____________________________________________________________________
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada