So I have the first working sketch of having a libdir with a shared
binary library included in it. This is on Mac OS X. There are some
limitations, I wanted to throw out what I have learned and see if
anyone has any input.
- Mac OS X DLLs are tied to their install location, that location can
be changed with install_name_tool, but it could be a bit weird. This
is already happening to included the Fink DLLs in the Pd-
extended.app. This means it would be not hard to manage DLLs for
libdirs within Pd-extended, but it would be for individually
distributed libdirs. "bundles" could be used instead of DLLs, but
would have to be explicitly loaded using dlopen().
- AFAIK, Windows will load DLLs in the same directory as the code
that wants to load the DLL, so it should be easy to include them in
both individually distributed libdirs and Pd-extended. I haven't
tested this in libdirs, but this works with a bunch of DLLs
distributed with Pd and Pd-extended. Otherwise we could use
LoadLibrary().
- AFAIK, on GNU/Linux, the .so just needs to be in the path, or
explicitly loaded with dlopen(). If Pd added '.' to the
LD_LIBRARY_PATH, then the .so could be just included in any libdir,
standalone or within Pd-extended.
So far, I don't have a clear idea of the best approach.
.hc
------------------------------------------------------------------------
----
kill your television