The Linker tab fields change depending on your selection in the Category dropdown list at the top:
By default, a generated application has the same name as the project it's built from. A library has a prefix of lib and a suffix of .a or .so after the project name. In addition, debug variants of applications and libraries have a suffix of _g.
Override the shared-object name used in C/C++ library projects. This setting doesn't affect the actual filename.
Select a version number for both the library's shared-object name and filename.
If the library doesn't have a version number (e.g., its filename is to be libxx.so with no numeric suffix), select No. This way, the shared-object name isn't hard-coded in the library.
To use versioning, you can leave the field setting as Default, in which case the IDE uses 1 as the version number, or select an exact version number within the available range. The filename is then libxx.so.n, where n is a number based on this setting. In this case, the shared-object name ends with so.n. The loader requires the library filename to be exactly like this because all dependent projects will refer to the library as so.n (in the NEEDED section of the executable).
If you use the IDE to upload libraries to the target when launching an application, the IDE silently renames each library file to the proper version, and makes a copy in the host directory so that the host tools (e.g., the debugger) can find it as well.
When a shared library is created, its name is documented in a special dynamic section of the library's binary file. When you link against the library, your application looks for that name.
When you run make install, the .so file is copied to .so.1, and a .so symbolic link is created to point to it. You'll notice that the .so gets the right version. If you install a .so.2 (where the .so points to it), your old version 1 clients can still run.
Select this category to modify the list of library paths to specify locations where the linker should look for import libraries
(.so or .a files) and to change the order in which they are referenced.
By selecting this category, you can define a list of libraries (.so or .a files)
to search for unsatisfied references.
For example, if you select Yes and you want to link against a debug version of the library, the IDE appends _g to the library's base name. If you select No, the builder passes (to ld) the specified name, exactly as you entered it. Therefore, if you want to use a release version of your binary and link against a debug version of the library, specify Yes for debug.
Note that setting this value appears to create errors with the library names in the common.mk file; however, the qnx_internal.mk included with common.mk corrects this problem.
You can add a library in three ways:
The remaining buttons are:
This category lets you link a project against any object file or library, regardless of the filename.
The file selection dialog may seem slow when adding new files. This is because the system can't make assumptions about naming conventions and instead must inspect a file to determine if it's an object file or library.
The Extra object files option is available for an individual platform only. If a project has more than one active platform, you can't use this feature. In that case, you can still specify extra object files using the advanced mode for each platform separately.
Select this category to specify a list of commands to apply (sequentially, in the order given) after building your project.
The buttons let you add and delete actions and move them up and down in the list. If you click Add, the resulting dialog provides radio buttons that let you choose one of these actions:
Depending on the action selected, additional fields in this second dialog let you specify what you want to copy or move, the destination (in your workspace or filesystem), the new name, and the shell command.