On Nov 5, 2011, at 12:47 PM, Mathieu Bouchard wrote:

> Le 2011-11-05 à 00:50:00, Hans-Christoph Steiner a écrit :
> 
>> The problem with changing t_widgetbehavior is that it breaks binary 
>> compatibililty, I think.
> 
> Yes, and I already had made extra-crunchy hacks in GridFlow so that it can be 
> binary-compatible with both Vanilla and Extended while doing m_imp.h hacks. 
> This was because Extended introduced the quite unnecessary m_blobmethod field.
> 
> So, I'd have to do another hack like that (but easier) to support L2Ork. I'm 
> not interested in distributing more binaries, so either Ivica distributes his 
> own GridFlow binaries, or preferably, I would have some code to auto-detect 
> L2Ork and act accordingly.
> 
> Coïncidentally, both binary-compat problems have to do with (different parts 
> of) the comment-inlet hack used in the GFDP helpfile «template».
> 
> There are similar binary-compat problems trying to deal with multiple 
> versions of Extended because GridFlow also links to GEM, which comes in 
> multiple binary-incompatible versions depending on the version of Extended.
> 
> GF supports 3 different ABIs of GEM, but now there's a new ABI that it isn't 
> compatible with yet. It's the 3rd different GEM ABI to be labelled «0.93» so 
> far. (but I don't remember which versions of GEM are bundled with Extended).

Is that a Pd-extended issue or a Gem issue? I don't really know much about 
Gem's guts or C++ linking.  I was under the impression this issue is related to 
C++ name mangling.

.hc


----------------------------------------------------------------------------

"Making boring techno music is really easy with modern tools, but with live 
coding, boring techno is much harder." - Chris McCormick





_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to