When you're building a shared object, you can specify the following option to qcc:
"-Wl,-hname"
(You might need the quotes to pass the option through to the linker intact, depending on the shell.)
This option sets the internal name of the shared object (SONAME) to name instead of to the object's pathname, so you'd use name to access the object when dynamically linking. The internal name must end with a version number (e.g., libxx.so.n and not merely libxx.so).
You might find this useful when doing cross-development (e.g., from a Windows system to a QNX Neutrino target). If several versions of a library provide the same interface, they'd have the same SONAME; if another version of the library is incompatible with earlier versions, its SONAME would be different.
For example, you might have several versions of the C library, and libc.so could be a symbolic link to the most recent version:
# ls -l libc.so* lrwxrwxrwx 1 root root 9 Oct 28 11:59 libc.so -> libc.so.4 -rwxr-xr-x 1 root root 28902 Jul 09 2010 libc.so.2 -rwxr-xr-x 1 root root 645784 Jun 20 2012 libc.so.3 -rwxrwxr-x 1 root root 904512 Oct 20 21:01 libc.so.4 # objdump -x libc.so.4 | grep SONAME SONAME libc.so.4 # objdump -x libc.so.3 | grep SONAME SONAME libc.so.3 # objdump -x libc.so.2 | grep SONAME SONAME libc.so.2 # objdump -x libc.so | grep SONAME SONAME libc.so.4
If you link against libc.so when it's a link to version 3, you won't be able to execute your program on a system that has only version 4 of the library.