On 22/07/10 20:07, Claude Heiland-Allen wrote:
On 22/07/10 05:09, Miller Puckette wrote:
Oh yes, and -lib itself needs somehow to be made to work locally to the patch, but this is a huge issue I don't know how to deal with.
At first glance it should be possible to have canvas-local objectmakers and have the "put on load list" put the absolute pathname of the dll instead of just the name, but maybe there are some libraries that simply cannot be dlopen()d more than once by the same executable due to clashing exported symbols or so? I don't know enough about dlopen() to say!
[snip]
$ cat foo/external.c #include <m_pd.h> extern int external_data; extern void external_setup(void) { post("foo/external: %d", external_data++); } int external_data = 42;
$ cat bar/external.c #include <m_pd.h> extern int external_data; extern void external_setup(void) { post("bar/external: %d", external_data++); } int external_data = 42;
$ pd -lib foo/external -lib bar/external -stderr -send "; pd quit" foo/external: 42 bar/external: 43
$ pd -version Pd version 0.42-5 compiled 20:01:18 Jan 5 2010
Now suppose that foo/external and bar/external have completely different semantics for 'external_data'. The consequence would be epic breakage. RTLD_DEEPBIND[1] might be beneficial in some cases (ie, self-contained libraries), but in others (ie, libraries that depend on other libraries, like Gem/pix_opencv, Gem/gridflow, pdp/pidip, pdp/pdp_opencv, etc) it would just postpone the epic breakage.
Conclusion: local libraries for local patches are impossible to implement, at least if you expect sane/safe behaviour.
Given this conclusion, what is the best we can do?
[1] RTLD_DEEPBIND (since glibc 2.3.4) Place the lookup scope of the symbols in this library ahead of the global scope. This means that a self-contained library will use its own symbols in preference to global symbols with the same name contained in libraries that have already been loaded. This flag is not specified in POSIX.1-2001. -- man dlopen
Claude