Sorry it is not currently documented properly, in a nutshell:
"so" version comes from linker option. If you using QNX project open Properties of library project and you can see that
Library version (in Linker tab) is "Default", which is "1". It is recommended to switch it to "No" which would mean that
 SONAME would not be hard coded in the library.

When it is "so.1", loader requires library to be called exactly like this because all dependent projects refer to is as 
so.1 (in NEEDED section of executable).
If you use IDE to upload libraries to target during launch it silently renames it to proper version and make a copy in 
host directory so host tools (such as debugger) can find it as well.
If you manually upload library to a target you have to manually rename it. Because it is not really convenient if you 
don't need to keep library versioning it is better not to use it at all (see 
comment #1 how to get rid of it)

Ken Schumm wrote:
> We're using a third party ARM math library that is built with the 4.2.1 compiler on windows hosted Momentics 6.3.2. 
The resulting shared object is named libgofast.so.
> 
> Other binaries are set up to link to it in the project properties, linker tab, Extra libraries dialog they are set to 
link to it with name 'gofast', type 'dynamic', and Use proper variant 'Yes'.
> 
> When these binaries are executed they complain that they cannot find 'libgofast.so.1'. Where did the version number 
'1' come from? 
> 
> This behavior seems inconsistent. We have written other shared objects that are linked and installed the same way and 
they never require a library version number.
> 
> Exactly what are the rules for how library version numbers are derived, when they are appended, how they are resolved,
 etc. Is this documented somewhere?
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post14527
> 

When you create a shared library, it's 'name' is recorded in a special 'dynamic' section.  You can
display the info in this section, eg

ntoarm-readelf -d libgofast.so

you will see a SONAME record.

When you link against this lib, then your app will subsequently look for that name.

You will notice that when you do a make install, the libgofast.so will get copied to libgofast.so.1, and a libgofast.so 
symbolic link  will be created point to it.
Then you when you pass -lgofast you will find libgofast.so which will get the right version.  If you install a libgofast
.so.2 (with libgofast.so pointing to it)
then your old version 1 clients can still run.

Colin

Ken Schumm wrote:
> We're using a third party ARM math library that is built with the 4.2.1 compiler on windows hosted Momentics 6.3.2. 
The resulting shared object is named libgofast.so.
> 
> Other binaries are set up to link to it in the project properties, linker tab, Extra libraries dialog they are set to 
link to it with name 'gofast', type 'dynamic', and Use proper variant 'Yes'.
> 
> When these binaries are executed they complain that they cannot find 'libgofast.so.1'. Where did the version number 
'1' come from? 
> 
> This behavior seems inconsistent. We have written other shared objects that are linked and installed the same way and 
they never require a library version number.
> 
> Exactly what are the rules for how library version numbers are derived, when they are appended, how they are resolved,
 etc. Is this documented somewhere?
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post14527
> 

-- 
cburgess@qnx.com