Building libraries for Qt apps

When writing applications, it's often necessary to use libraries to store specific functionality (e.g., graphics functions, filesystem access). On QNX targets, apps run in sandbox environments with limited access to system facilities, meaning that their required functionality must be contained in libraries accessible in the sandbox.

In the QNX Qt environment, an app can either statically or dynamically link in its required libraries. With static linking, the app links the static object-code library (.a) files into its executable. This strategy ensures that the required library functionality is always accessible to the app. With dynamic linking, the libraries are stored in "shared library" (.so) files that are included in the app package. At runtime, the app binary must load these files.

Each app must package all the .so files it needs because the separate sandboxes for separate apps mean that apps can't actually share dynamic libraries. Therefore, when a given library is included in an app, the package size increases by the same amount whether the library is statically or dynamically linked. Also, when one of its libaries is upgraded, the app must be repackaged and redeployed.

While static linking is the recommended option, it may not always be possible due to licensing restrictions or other issues. When dynamic linking is the only option, special considerations apply for the sandbox environment. The tutorial that follows demonstrates how to dynamically link a library into an app and then deploy the library as part of the BAR package.

Note: In our example, we will create a "third-party" library for use by our QtApp sample. Typically, a third-party library comes from an outside source such as a public project or a vendor.