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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
