[omniORB] Fix for Python shared lib suffix for Python 3.11+

[Glen Walker]

Hi Duncan,

I am currently upgrading some software, that uses omniORBpy, to add support
for Python 3.11 and 3.12, and I noticed that the omniORBpy C extension
shared libraries are no longer built with suffixes of the form
".cpython-310-x86_64-linux-gnu.so" for Python 3.11+ on Linux, and are
instead built with a plain ".so" extension (e.g. _omnipy.so rather than _
omnipy.cpython-311-x86_64-linux-gnu.so). Python still supports loading C
extensions with plain ".so" suffixes, so the C extensions still work, but
it does mean it is no longer possible to deploy shared libraries for
multiple Python versions to the same directory. After a little bit of
digging I believe that this change was accidental rather than deliberate.

The file mk/python.mk in both omniORB and omniORBpy sets the value of
PythonSHAREDLIB_SUFFIX based on the Python sysconfig variable "SO". The
sysconfig variable "SO" was replaced by the variable "EXT_SUFFIX" in Python
3.2, was deprecated in Python 3.7, and has been removed in Python 3.11.
When the value of "SO" is None python.mk currently falls back to using
".so" as the suffix, which is the source of the issue in Python 3.11+.

Please find attached a patch to mk/python.mk for both omniORB and omniORBpy
that restores the full suffix to omniORB Python C extensions, making them
consistent with Python < 3.11.

Kind regards,
Glen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20240216/a706860d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python.mk.patch
Type: application/octet-stream
Size: 939 bytes
Desc: not available
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20240216/a706860d/attachment.obj>