hi all,
quick q: what happens if there is a name clash between two externals from different libs (or the same lib) ?
tom
On Sat, 18 Jan 2003, Tom Schouten wrote:
hi all,
quick q: what happens if there is a name clash between two externals from different libs (or the same lib) ?
tom
Is this a theoretical or practical question ? There are two solutions, one is to avoid name clashes. The other one is using namespaces. (There is a patch from Johannes for that).
I think it is better to avoid name clashes. Not technically, but in order to improve communication between external developers and avoid duplication of work and functionality.
Greetings,
Guenter
quick q: what happens if there is a name clash between two externals from different libs (or the same lib) ?
Is this a theoretical or practical question ?
practical.. i agree its better to avoid it, but i was wondering if the behaviour is predictable when it happens. if you have i.e.
class1 = class_new(gensym("object"), ... class2 = class_new(gensym("object"), ...
which class gets instantiated if you create [object] in pd?
first, second or undefined?
Hi Tom.
I asked a similar question in this thread a while ago: http://www.iem.at/mailinglists/pd-list/2002-November/001236.html
The key answer I got was from Krzysztof Czaja:
It seems like in each system Pd loads externals differently. Windows .dll does not export external symbols, .pd_linux does (with the flag RTLD_GLOBAL) -- but dlopen kindly resolves any name clashes -- and now you tell that .pd_darwin is so fragile... You are right, something needs to be done to unify loader's behaviour.
One of the most significant changes in the pd_devel_0.36 branch of MacOSX is that the behaviour goes from a duplicate symbol causing a crash to a duplicate symbol being ignored.
Tom Schouten said this at Sat, 18 Jan 2003 13:08:41 +0100:
class1 = class_new(gensym("object"), ... class2 = class_new(gensym("object"), ...
which class gets instantiated if you create [object] in pd?
first, second or undefined?
Practically, the behaviour on Mac is undefined (official version) or first (modified s_loader with NSLINKMODULE_OPTION_PRIVATE).
-
Adam Lindsay -
guenter geiger -
Tom Schouten