0

I have searched here and Google and can't find the answer to this.

I have a python code (a library) I made and tested that it works. However, I want to compile it to an .so library and still use it in Python scripts (I know some think I'm mad but just humor me a moment...)

I am using Cython3 to do this and it does compile. But if I run it on a system with a different version of python installed (ie. compiled on a system with Python 3.5 and run on a system with Python 3.4) then I get the following error:

_frozen_importlib:321: RuntimeWarning: compiletime version 3.5 of module 'mynewlib' does not match runtime version 3.4

It's essential that these warnings don't pop up every time I run a python script that includes this module (ie. from mynewlib import *)

What if I compiled it on the target system but then the target system's python gets upgraded a point version? Then these errors would only come up again.

Is there a solution to this? Here is the code from my script that compiles the python code:

    cython3 -a -3 --lenient $MODULE_NAME.py
gcc -shared -pthread -fPIC -fwrapv -O2 -Wall -fno-strict-aliasing -I/usr/include/python3.5 -o $MODULE_NAME.so

Are there any other command line options I should change? In the gcc line I have -Wall but is there some way I can change that to exclude these python version warnings?

I don't have any problems when including the compiled library in my scripts. The functions all work fine. So it seems I can safely ignore the warnings.

However, there are some instances where I need to get the output of the script and having these warnings spewing out only breaks things.

How do I suppress the warnings?

  • 1
    You should not ignore the warning but compile your module with the right Python version. See cython documentation about installation with a setup-script. – ead Feb 15 '19 at 20:30
  • Taken literally this could be a duplicate of https://stackoverflow.com/questions/14463277/how-to-disable-python-warnings. But I agree with @ead - the warning is there for a reason – DavidW Feb 15 '19 at 22:30
  • That isn't too portable and can lead to problems if the system ends up upgraded to the next point version of python. Then something will break before you realize that you need to recompile another version due to an automatic update. –  Feb 15 '19 at 22:35
  • Thank you both. @DavidW your link is a good answer as well. I've ultimately have decided on a different approach to my project that is more stable. Both of you gave me something to think about. –  Feb 16 '19 at 13:26
  • 1
    I think that's sensible. I did have a couple of small suggestions that might be worth knowing: 1) if you compile with `setup.py` you get a .so named with a version number (e.g. `something.cpython_3.5.so`) - this will only import if the version matches so gives safety. 2) If you're prepared to write C code, Python defines a ["stable C ABI"](https://docs.python.org/3/c-api/stable.html) which is limited, but is compatible between versions – DavidW Feb 16 '19 at 14:18

0 Answers0