[PD-dev] local libraries for local patches are impossible

Claude Heiland-Allen claudiusmaximus at goto10.org
Tue Jul 27 23:56:31 CEST 2010


On 27/07/10 22:41, Claude Heiland-Allen wrote:
> 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.

Example of such:

$ cat foo/external.c
#include <m_pd.h>
extern short int external_data;
extern void external_setup(void) { post("foo/external: %d", 
external_data++); }
short int external_data = -42;

$ cat bar/external.c
#include <m_pd.h>
extern const char external_data[];
extern void external_setup(void) { post("bar/external: %s", 
external_data); }
const char external_data[] = "bar";

$ pd -lib foo/external -lib bar/external -stderr -send "; pd quit"
foo/external: -42
bar/external: ×ÿ

> 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




More information about the Pd-dev mailing list