Specifying an internal name

Updated: April 19, 2023

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.5
-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.5
# objdump -x libc.so.5 | grep SONAME
  SONAME               libc.so.5
# 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.5

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.