Mercurial > hg > vamp-plugin-sdk
comparison build/README.osx @ 292:2fc6456b1c71
* note about install_name
author | cannam |
---|---|
date | Tue, 22 Sep 2009 10:08:01 +0000 |
parents | 2e16d99867bd |
children | c70e1ceb1eff |
comparison
equal
deleted
inserted
replaced
291:2e16d99867bd | 292:2fc6456b1c71 |
---|---|
40 | 40 |
41 | 41 |
42 Plugin Linkage | 42 Plugin Linkage |
43 -------------- | 43 -------------- |
44 | 44 |
45 Vamp plugins are distributed as dynamic libraries (.dylib). A | 45 Vamp plugins are distributed as dynamic libraries (.dylib). An OS/X |
46 well-packaged Vamp plugin library should export exactly one public | 46 dynamic library has a formal installed name, which is recorded in the |
47 library's header: you will need to ensure that this matches the | |
48 plugin's filename (e.g. vamp-example-plugins.dylib) by using the | |
49 -install_name <name> option at link time. The Makefile.osx provided | |
50 with the SDK contains an example of this. | |
51 | |
52 A well-packaged Vamp plugin library should export exactly one public | |
47 symbol, namely the Vamp API entry point vampGetPluginDescriptor. | 53 symbol, namely the Vamp API entry point vampGetPluginDescriptor. |
48 | 54 |
49 The default for the OS/X linker is to export all of the symbols in the | 55 The default for the OS/X linker is to export all of the symbols in the |
50 library. This will work (the host will be able to load the plugin), | 56 library. This will work (the host will be able to load the plugin), |
51 but it unnecessarily pollutes the host's symbol namespace, it may | 57 but it unnecessarily pollutes the host's symbol namespace, it may |