You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not a huge issue really, but it can lead to an odd situation.
If you do a debug install of the Python module, CMake may stick a suffix to the shared library name. But the module name no longer matches the exported name.
Importing the new name wont work, for example on my Linux:
>>> import OpenEXR_d.so
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define module export function (PyInit_OpenEXR_d)
An obvious workaround is to simply rename/symlink the file to OpenEXR[.so/dll]after install.
I suspect it is a very niche case few people will encounter. It is however quite confusing unless you know your way around Python bindings.
One fix is to just make sure the module export name matches the CMake output name, although this is also a bit confusing. Disabling the suffix might be the least surprising behaviour?
The text was updated successfully, but these errors were encountered:
This is not a huge issue really, but it can lead to an odd situation.
If you do a debug install of the Python module, CMake may stick a suffix to the shared library name. But the module name no longer matches the exported name.
Importing the new name wont work, for example on my Linux:
An obvious workaround is to simply rename/symlink the file to
OpenEXR[.so/dll]
after install.I suspect it is a very niche case few people will encounter. It is however quite confusing unless you know your way around Python bindings.
One fix is to just make sure the module export name matches the CMake output name, although this is also a bit confusing. Disabling the suffix might be the least surprising behaviour?
The text was updated successfully, but these errors were encountered: