[Gridflow-dev] GridFlow 9.13 source released

Mathieu Bouchard matju at artengine.ca
Tue Feb 8 10:30:19 EST 2011


On Tue, 8 Feb 2011, Mathieu Bouchard wrote:

> but there's a slight problem : it won't say -lGL, etc. by default, thus, when 
> GEM is lot loaded, it gets undefined symbol, if GL was enabled in 
> ./configure.
>
> For this, just apply the diff of r6579.
>
> Thanks to Claude for finding the bug.
>
> http://gridflow.ca/download/gridflow-9.13.tar.gz

Just to give some more détails on what it is : it's that a uses_so 
directive used to be adding -lblah and/or -L/usr/blah/lib options to the 
gcc command that makes the gridflow.pd_linux (or equivalent name). This is 
no longer always the case, as the produces_pdlib can redirect those 
options to a different gcc command(s), such as the ones that are building 
the four gridflow_gem_*.pd_linux files (or equivalent names). With a 
single Feature.new{} block, you can't say "the gridflow lib needs the GL 
libs" and "the gridflow_gem libs need the GL libs" at the same time, so, 
it "has" to be split into two Feature.new{} blocks.

But this new mechanism is still a bit of a prototype, and it's possible 
that by gridflow-9.14, the configure-file works in a newer way.

BTW, I'm still open to a switch to autoconf/automake, but keep in mind 
that if that means that ./configure gets replaced by new source code that 
is longer than the current ./configure, it might not be worth it. I don't 
know enough aobut that software to quickly make a replacement for the 
current ./configure script (which is written in Ruby, without dependency 
on autoconf/automake at all). If any of you guys can tell me what you 
think about this...

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC


More information about the Gridflow-dev mailing list