<div dir="ltr"><div>Hi Duncan,</div><div><br></div><div>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 _<a href="http://omnipy.cpython-311-x86_64-linux-gnu.so">omnipy.cpython-311-x86_64-linux-gnu.so</a>). 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.</div><div><br></div><div>The file mk/<a href="http://python.mk">python.mk</a> 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 <a href="http://python.mk">python.mk</a> currently falls back to using ".so" as the suffix, which is the source of the issue in Python 3.11+.</div><div><br></div><div>Please find attached a patch to mk/<a href="http://python.mk">python.mk</a> for 
 both omniORB and 
omniORBpy that restores the full suffix to omniORB Python C extensions, making them consistent with Python < 3.11.</div><div><br></div><div>Kind regards,</div><div>Glen<br></div></div>