Fix for Python shared lib suffix for Python 3.11+

--000000000000c22fcf06117fc2f5
Content-Type: multipart/alternative; boundary="000000000000c22fcd06117fc2f3"

--000000000000c22fcd06117fc2f3
Content-Type: text/plain; charset="UTF-8"

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

--000000000000c22fcd06117fc2f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Duncan,</div><div><br></div><div>I am currently up=
grading 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 &quot;.cpython-310-x86_64-linux-=
gnu.so&quot; for Python 3.11+ on Linux, and are instead built with a plain =
&quot;.so&quot; extension (e.g. _omnipy.so rather than _<a href=3D"http://o=
mnipy.cpython-311-x86_64-linux-gnu.so">omnipy.cpython-311-x86_64-linux-gnu.=
so</a>). Python still supports loading C extensions with plain &quot;.so&qu=
ot; suffixes, so the C extensions still work, but it does mean it is no lon=
ger possible to deploy shared libraries for multiple Python versions to the=
 same directory. After a little bit of digging I believe that this change w=
as accidental rather than deliberate.</div><div><br></div><div>The file mk/=
<a href=3D"http://python.mk">python.mk</a> in both omniORB and=20
omniORBpy sets the value of PythonSHAREDLIB_SUFFIX based on the Python sysc=
onfig variable &quot;SO&quot;. The sysconfig variable &quot;SO&quot; was re=
placed by the variable &quot;EXT_SUFFIX&quot; in Python 3.2, was deprecated=
 in Python 3.7, and has been removed in Python 3.11. When the value of &quo=
t;SO&quot; is None <a href=3D"http://python.mk">python.mk</a> currently fal=
ls back to using &quot;.so&quot; as the suffix, which is the source of the =
issue in Python 3.11+.</div><div><br></div><div>Please find attached a patc=
h to mk/<a href=3D"http://python.mk">python.mk</a> for=20
 both omniORB and=20
omniORBpy that restores the full suffix to omniORB Python C extensions, mak=
ing them consistent with Python &lt; 3.11.</div><div><br></div><div>Kind re=
gards,</div><div>Glen<br></div></div>

--000000000000c22fcd06117fc2f3--
--000000000000c22fcf06117fc2f5
Content-Type: application/octet-stream; name="python.mk.patch"
Content-Disposition: attachment; filename="python.mk.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_lsoopy7p0>
X-Attachment-Id: f_lsoopy7p0

LS0tIC4vb21uaU9SQnB5LTQuMy4xL21rL3B5dGhvbi5tayAgMjAyMy0wNy0xMyAyMjozODo1NC4w
MDAwMDAwMDAgKzEyMDAKKysrIC4vcHl0aG9uLm1rIDIwMjQtMDItMTYgMjM6NTg6MTMuMzIwMTc1
MDAwICsxMzAwCkBAIC02LDcgKzYsNyBAQAogUFlQUkVGSVggIDo9ICQoc2hlbGwgJChQWVRIT04p
IC1jICdpbXBvcnQgc3lzOyBzeXMuc3Rkb3V0LndyaXRlKHN5cy5leGVjX3ByZWZpeC5yZXBsYWNl
KCJcXCIsIi8iKS5yZXBsYWNlKCIgIiwiXFwgIikpJykKIFBZSU5DRElSICA6PSAkKHNoZWxsICQo
UFlUSE9OKSAtYyAnaW1wb3J0IHN5cywgc3lzY29uZmlnOyBzeXMuc3Rkb3V0LndyaXRlKHN5c2Nv
bmZpZy5nZXRfcGF0aCgiaW5jbHVkZSIpLnJlcGxhY2UoIlxcIiwiLyIpLnJlcGxhY2UoIiAiLCJc
XCAiKSknKQogCi1QeXRob25TSEFSRURMSUJfU1VGRklYID0gJChzaGVsbCAkKFBZVEhPTikgLWMg
J2ltcG9ydCBzeXMsIHN5c2NvbmZpZzsgc3lzLnN0ZG91dC53cml0ZSgoc3lzY29uZmlnLmdldF9j
b25maWdfdmFyKCJTTyIpIG9yICIuc28iKS5sc3RyaXAoIi4iKSknKQorUHl0aG9uU0hBUkVETElC
X1NVRkZJWCA9ICQoc2hlbGwgJChQWVRIT04pIC1jICdpbXBvcnQgc3lzLCBzeXNjb25maWc7IHN5
cy5zdGRvdXQud3JpdGUoKHN5cy5oZXh2ZXJzaW9uIDwgMHgwMzAyMDAwMCBhbmQgc3lzY29uZmln
LmdldF9jb25maWdfdmFyKCJTTyIpIG9yIHN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiRVhUX1NV
RkZJWCIpIG9yICIuc28iKS5sc3RyaXAoIi4iKSknKQogCiBQWV9NT0RVTEVfU1VGRklYIDo9ICQo
c2hlbGwgJChQWVRIT04pIC1jICdpbXBvcnQgc3lzOyBzeXMuc3Rkb3V0LndyaXRlKChzeXMuaGV4
dmVyc2lvbiA8IDB4MzAwMDAwMCBhbmQgbm90IGhhc2F0dHIoc3lzLCAicHlweV92ZXJzaW9uX2lu
Zm8iKSkgYW5kICJtb2R1bGUiIG9yICIiKScp
--000000000000c22fcf06117fc2f5
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list

--000000000000c22fcf06117fc2f5--