On Fri, 16 Oct 2009, IOhannes m zmölnig wrote:
Mathieu Bouchard wrote:
Basically, all Gem externals that are outside of the main Gem library have to be recompiled once in a while, to match the Gem ABI.
the same holds true for all Gem externals that are inside the main Gem library and/aka "internals". the process is more automated, though.
Yeah, I'm saying that _especially_ because it's less automated one way than the other. And people only notice it when they get "undefined symbol" or whatever. This can happen with any Pd library that other Pd libraries link to, in any machine code format (.pd_linux, etc), but it tends to happen more with Gem because Gem is quite popular.
Perhaps Johannes has a few words to say about how this change happened?
Revision: 2978 virtual void report(const char*origin=NULL) const throw();
Well, I meant, what kind of change it was, for what purpose.
I would very much like to have a stable extendable API, and it's somewhere on my TODO-list. the current API is rather hmmm.
Yeah, I know what you mean. It's everybody's sweetest dream and yet it's everybody's nearly-last item on the todo list, and that's not by lack of good intentions...
anyhow, all in all: use the version of Gem you compiled/linked your Gem-external with.
Yeah. I think that Pd-extended does make that easier. In the future, people will use even more precompiled externs with Pd. Pd-extended has had quite a tremendously good impact on Pd, and I don't just mean no more new pd-list threads about -Werror every week or so. ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801