[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