Another workaround may be to build _csnd and _CsoundVST in
such a way that a dylib is created from all the object files
with the exception of the SWIG wrappers, while a bundle is
also built that contains only the SWIG wrappers and links
against the dylib. So, we would have:

  lib_csnd.dylib      (depends on CsoundLib)
  _csnd.so            (depends on lib_csnd.dylib)
  lib_CsoundVST.dylib (depends on lib_csnd.dylib)
  _CsoundVST.so       (depends on lib_CsoundVST.dylib)

Of course this would only be done on OS X, and the cost is
more complicated code in SConstruct.

On Thursday 25 May 2006 20:41, Victor Lazzarini wrote:

> yes, you are right, but there are two different and separate
> files: lib_csnd.dylib and _csnd.so. They are built
> separately
> and used differently. The same strategy might be tested for
> csoundVST.
> 
> > On Thursday 25 May 2006 19:10, Michael Gogins wrote:
> >
> > > What is the difference between a bundle and a dylib,
> > anyway?
> >
> > Bundles are intended for dynamic loading as plugins at
> > run-time, while dylibs are libraries that can be linked
> > against. However, it is possible for an application to use
> > a dylib as a plugin - even if this is not the recommended
> > approach - since Csound does exactly that, but for some
> > reason Python can only load bundles.
> > Note that _csnd is built as both a dylib and a bundle on
> > OS X, so that C++ programs can link against it, while
> > Python scripts can "import csnd". It is not clear if doing
> > both in the same process is safe, though.