added SOVERSION for symlinked library generation from just a version number

[dmoody256]

This PR covers just the SOVERSION updates from #3661

The SOVERSION is a new environment variable which works very similar to the SONAME environment variable, except instead of providing the full library name as you do with SONAME, you just provide an number which will generally be the major version number in the symlinked library.

The SHLIBVERSION environment variable is also very similar to this, except that the SHLIBVERSION is generally the specific version number of the library, and used on the actual output library, instead of the symlinked library.

Please review https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html for more information on the standard conventions for library versioning in linux.

Also note that macOS uses a similar convention for versioning libraries, so this PR also adds the variable to apple linker.

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt (and read the README.rst)
• I have updated the appropriate documentation

[bdbaddog]

Why remove using supplied SONAME?

[dmoody256]

This was not the correct order of the calling functions. ShLibSonameGenerator calls into LINKCALLBACK, which calls this function if SONAME is not supplied. Since ShLibSonameGenerator calls to the more specific naming functions, it should handle SONAME and SOVERSION in ShLibSonameGenerator, and then pass the naming info down.

[bdbaddog]

Expand upon the SONAME generated when SOVERSION is specified. (what would it be in the example above)

[dmoody256]

done in 13527e8

[bdbaddog]

Why change this?

[dmoody256]

ShLibSonameGenerator ends up calling that linkcallback if SONAME is not supplied. Without this change, the ShLibSonameGenerator is skipped out.

[dmoody256]

Ok tests are failing now that I removed that code I thought was left from the SONAME_GENERATOR. Maybe I took too much away, once I get a minute I'll go check it.

[bdbaddog]

So if we allow setting SOVERSION (in place of setting SONAME) it should have the following impact:

1. the soname set in the shared library should be libname.SOVERSION
2. The chain of symlinks should be as below, where libname.so.SHLIBVERSION is the actual file.

   libname.so -> libname.so.SOVERSION
   libname.so.SOVERSION -> libname.so.SHLIBVERSION

3. For apple, the flag link flags:
   gcc -o libfoo.SHLIBVERSION.dylib -dynamiclib -Wl,-current_version,SHLIBVERSION -Wl,-compatibility_version,SOVERSION.o foo.os
4. For gnu the link flags should be
   gcc -o libfoo.so.SHLIBVERSION -shared -Wl,-soname=libfoo.so.SOVERSION foo.os

In the case we have SONAME and not SOVERSION, should we extract the SOVERSION from SONAME for use in the -compatibility_version?

Note we also have the following env vars

• APPLELINK_NO_CURRENT_VERSION - don't specify a -current_version
• APPLELINK_CURRENT_VERSION - use this for the -current_version and don't extract from SHLIBVERSION
• APPLELINK_NO_COMPATIBILITY_VERSION - don't specify a -compatibility_version
• APPLELINK_COMPATIBILITY_VERSION - use this for -compatibility_version and don't extract from SHLIBVERSION

The apple bits aren't really (yet) addressed in this PR.
(Note there's also some validation of the version numbers for apple. 0-65536[.0-255[.0-255]] are the only valid formats for those numbers and there's pre-existing code to check that)

Of note, some PR's for meson and links to cmakes implementation details

• Generate shared library version arguments on macOS mesonbuild/meson#1451
• https://github.com/mesonbuild/meson/blob/master/test%20cases/osx/2%20library%20versions/CMakeLists.txt
• Improve support for macOS dylib versioning mesonbuild/meson#4095
• https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html

I'm guessing it's better for our user base if we match cmake/meson's implementations (rather than libtool, especially for apple).

[bdbaddog]

Closing in favor of PR #3848 which is a rewrite of existing logic and implements this logic as well.