Hi Chris and list,

well, I know that this nameclash exists. But I don't know what to do.... maxlib's scale is identical to the scale in Max (but scale is not a native Max object, I think) so it makes sense to keep it's name for compatibility reasons. On the other hand Gem's scale has been introduced earlier and is used in quite a lot of patches, I guess.

I could add an option to maxlib that would prepend all the object names with 'maxlib_' to avoid nameclashes. But this could only be included during compilation and would produce quite long object names. And leaving it an option one would need to know which version was used for a patch before being able to open it.

The problem we're facing here is not the only one where nameclashes occur. On thursday Eric Skogen posted a mail to the list asking for help with a similar problems. I'll also post this mail to the pd list since we had this discussion several times but never really got to a definite solution, I think. Or did I miss anything?

Olaf

PS: the error message is OS X only, Linux and Win just ignore the second definition and create the object that has been loaded first... maybe there is an option that can be set to ignore this error and to force the behaviour found on Linux?

chris clepper schrieb:

Hi Olaf

I was just talking to a Gem beta tester who mentioned that there is a multiple definition of symbol _scale_setup when using both Gem and maxlib. Maxlib seems way too useful to have to choose between it and Gem. Has this been brought up before??

errors:

/pd/bin/pd multiple definitions of symbol _scale_setup Gem.pd_darwin definition of _scale_setup maxlib.pd_darwin definition of _scale_setup

cgc