[PD-dev] local libraries for local patches are impossible [Was: Re: 0.43 omission: 'set-startup' and 'set-path']

[Claude Heiland-Allen]

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
-- 
http://claudiusmaximus.goto10.org