RFC: Finalize SO versioning to deal with ABI differences between versions of GFortran

[zbeekman]

Two proposals:

1. Set SOVERSION to the MAJOR version of GFortran we're building against/for

• CONS: What if interface changes between minor versions? Accelerate to high SOVERSIONS (i.e., 6 and 7) and can never decrement
• PROS: Less confusing, immediately identify which version of GCC the shared/dynamic lib is built for

2. Bump SO version for GCC < 7 to 2 (currently everyone is at 1) and to 3 for GCC 7.

• CONS: Less straight forwards
• PROS: More flexibility: Can convert to the other system later, as long as SOVERSION <= GCC major version, and can increment SOVERSION if an interface change happens between minor releases.

So far, the consensus seems to be to prefer scheme 2. Waiting a little bit longer before making the final decision.

CC: @vehre @afanfa @rouson @jerryd @mexas @amckinstry

Further discussion

• Client code is essentially standard conforming Fortran. As such, no calls should be made directly to the OpenCoarrays library except those generated by the compiler.
• Fortran has no standardized ABI, so the OpenCoarrays extensions module needs to be matched to the compiler (vendor and version) no matter what.
• Compiler generated calls interface with OpenCoarrays. These are transparent to the users (client code) due to the first point, but the version of the OpenCoarrays library needs to match interfaces with the Fortran compiler (right now only GFortran) used to compile the client code.
• Therefore, my/our current understanding is that the SOVERSION needs to be used to ensure a consistent interface between OpenCoarrays and GFortran generated calls to OpenCoarrays. Whenever this interface changes, the SOVERSION will need incrementing.
• Static libraries are easier to control because they can be put in e.g. lib/gcc/6 and hard-coded in the wrapper scripts, along with hardcoding the path to the compiler (see RFC: Hard code full paths and more precisely specify linker/compiler flags & MPI flags in caf and cafrun scripts #268)

Please feel free to chime in with additional points/considerations