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