The command dyld(1) calls global static initializers in the order they are linked into your application. From the API main page look under the category of "Concepts" for the topic named "Plugins". Each type of plugin should be located within a specific subdirectory (such as imageformats or sqldrivers) within your distribution directory.įor more information about creating and deploying a plugin refer to the CopperSpice API. Be sure to distribute any plugins which are required fro your application. Your application may also depend on one or more plugins, such as the JPEG image format plugin or a SQL driver plugin.
SAMPLE MAC OS FRAMEWORK MAC OS X
Mac OS X Version DependenciesĬopperSpice applications can be built and deployed on Mac OS 10.12 and higher.įor more information about cross development issues on Mac OS X, refer to: SDK Compatibility Guideįor more information about C++ runtime environment, refer to: C++ Runtime Environment Programming Guide Plugin Dependencies Unlike the deployment processes on Deploying on Unix and Deploying on Windows, compiler specific libraries may not need to be redistributed with your application.
SAMPLE MAC OS FRAMEWORK INSTALL
Install NameĪs an example, if your dynamic library is located in MyApp.app/Contents/Frameworks, the install name should be exactly as follows:
Our sample Makefile will automatically correct the install name. This is done by changing the install name after your application has been linked. For your application to find the bundled dynamic libraries they must have the correct 'install name'. The hard coded path was added to the CS dynamic libraries by the linker. The hard coded path inside the dynamic libraries are initially invalid. Our sample Makefile will automatically create the "Contents/Frameworks" directory and copy the CopperSpice dynamic libraries into the bundle when you run 'make install'. The preferred location for dynamic libraries is MyApp.app/Contents/Frameworks.
To use the CopperSpice dynamic libraries in a Mac OS X application, the libraries must be embedded in the application bundle. To find where the application bundle resides on the disk, use QCoreApplication::applicationDirPath() to determine the path of the binary within the bundle.įor more information about using the CFBundle API refer to: CF Bundle Reference
SAMPLE MAC OS FRAMEWORK HOW TO
Refer to the Deploying on Unix for information about how to deploy 'bundle-less' applications. If you are writing a command line application, it is not advisable to use a bundle. app.įor more information about bundles, refer to the following: OS X Developer Library - Bundles A Mac OS X application bundle is actually a directory, ending with. A bundle for an application typically contains the executable and all the resources it needs. A bundle is a directory structure that appears as a single entity when viewed in the Finder.
Mac OS X GUI applications must be run from a bundle. Refer to our sample project files for details about how to compile and link your application. The most common way to distribute an application bundle is to provide a compressed disk image (.dmg file) the user can mount in Finder. Third party libraries are normally not installed system wide. The bundle contains the application executable as well as dependencies such as the libraries, plugins, translations, and other resources users may need. Mac applications are deployed as self contained bundles.