Does Aspose.Slides for Python via .NET Work On macOS?

Aspose.Slides Product Family
,
21

@bowespublishing,
I am still waiting for a response from our developers and will let you know as soon as possible.

22

Any update on this please?

23

@bowespublishing,
Unfortunately, I have no additional information about the issue. The problem has a normal priority. There have been no updates yet.

24

Hi, I believe I’m facing the same issue. Running aspose.slides commands on MacOS cause segmentation faults when following your install instructions here: Installation|Aspose.Slides for Python Documentation

Any update would be appreciated!

1 Like
25

@alrdebugne,
Unfortunately, the issue is still open. We apologize for any inconvenience.

26

@bowespublishing,
The error you reported indicates that your Python is misconfigured and the integrity of your Python installation is broken. For using Python binary extensions (such as Aspose.Slides), a Python configuration must meet the following requirements:

  1. Python must be configured/built with the --enable-shared option, and as a result, should contain a separate Python shared library module file, libpythonX.Y.dylib, where X.Y is the Python version number, e.g. libpython3.9.dylib.
  2. The OS environment must be configured in such a way that the Python shared library can be found and loaded by the system’s shared library loading tools (the dlopen function).

To resolve the error you reported, please follow these steps:

  1. If you have placed any additional copies of the Python shared library file(libpythonX.Y.dylib) in your system directories, remove those copies.
  2. Make sure the Python instance you are using has been configured with the --enable-shared option. The value of the configuration variable shown below can help you with this:
    import sysconfig
    sysconfig.get_config_var('Py_ENABLE_SHARED')

Also, make sure your Python installation actually contains the Python shared library file - libpythonX.Y.dylib.

On macOS, this file is typically contained in one of the following directories (on the examples of Python 3.9):
/usr/lib/
/usr/local/lib/
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/
/usr/local/Cellar/python@3.9/3.9.14/Frameworks/Python.framework/Versions/3.9/lib
for Python instances managed by the pyenv utility:
/Users//.pyenv/versions/3.9.14/lib

Please note that on macOS versions of Python, the libpythonX.Y.dylib file can be a symbolic link to a Python interpreter file (which is perfectly acceptable).

If your Python was not originally configured with the --enable-shared option, then do the following steps:

2.1. It is highly recommended to uninstall your current (without --enable-shared) version of Python. This step is obligatory if you are using the pyenv utility to manage Python installations.

2.2. Install Python via a package manager, or build Python from the source with --enable-shared option.

If you have previously installed a “with --enable-shared” Python version over a “without --enable-shared” Python version, without first completely uninstalling the previous installation (especially when using the pyenv utility), please remove the current installation and do a “clean” install again, following the advice above.

  1. Make sure that the Python shared library file (libpythonX.Y.dylib) can be found and loaded using the standard macOS shared library loading tools (the dlopen function). If the Python shared library file (libpythonX.Y.dylib) is not located in the system’s standard shared library directory (unfortunately, this can be the case on macOS), use one of the two methods below:

3.1. Create a symbolic link to the actual Python shared library file (libpythonX.Y.dylib) in the standard system directory for shared libraries (usually /usr/lib or /usr/local/lib).

ln -s /usr/local/Cellar/python@3.9/3.9.14/Frameworks/Python.framework/Versions/3.9/lib/libpython3.9.dylib /usr/local/lib/libpython3.9.dylib

OR

3.2. Add the directory where the Python shared library file (libpythonX.Y.dylib) is actually located to the list of directories to search for shared libraries (usually this is the DYLD_LIBRARY_PATH variable value).

export DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH}:/usr/local/Cellar/python@3.9/3.9.14/Frameworks/Python.framework/Versions/3.9/lib/libpython3.9.dylib /usr/local/lib

You can also use the ~/.bashrc file to permanently set the value of the DYLD_LIBRARY_PATH variable.

  1. Please don’t try to copy/move the Python shared library file itself to other directories. Please do not attempt to place/install additional copies of the Python shared library file in system directories. Doing so will break the integrity of Python’s mechanism for loading binary extensions, and is guaranteed to result in fatal errors like the one you report.

Our development team is constantly working to make the process of installing our Python extensions easier and more convenient, and we may be able to minimize the inconvenience associated with depending on the Python shared library, but for now, we ask you to follow our recommendations as closely as possible and do not consider them as a field for experiments, otherwise we will not be able to help you.

The error you reported occurs if the Python shared library module (libpythonX.Y.dylib) that tries to use the aspose.slides binary is “stand-alone” in relation to the current Python interpreter, meaning it’s not part of the Python interpreter installation (in a session of which you are trying to import aspose.slides) and is not used by that interpreter itself. As a result, static objects and singletons declared in the Python shared library code that must be initialized when the Python interpreter starts up remain uninitialized and attempts to access these objects result in fatal errors like the one you report. Specifically, in your case, as the stack dump you reported suggests, the error occurs when you try to access an uninitialized dictionary of interned strings.

27

Thank you for the detailed response and instructions. I can successfully run Aspose.Slides now on my system however if you try to package everything into one bundle or application (cx_Freeze, Pyinstaller etc) which you distribute and use without installing python it doesn’t work and I get the same error. Do you know how to fix this?

28

@bowespublishing,
Thank you for the question. I’ve forwarded it to our developers. We will get back to you ASAP.

29

@bowespublishing,
As we have explained before, a Python interpreter binary may be built with or without a separate shared library file, and as a result, the built interpreter may or may not be compatible with binary extensions (such as aspose.slides). As far as we can understand, the most likely way to implement the bundling you mentioned is embedding Python to a binary application and running the bundled Python scripts in the embedded Python interpreter (see, 1. Embedding Python in Another Application — Python 3.12.0 documentation). Such embedding can also be done with different configuration option values, and as a result, the embedded Python interpreter may or may not be compatible with binary extensions. Please note that such bundling is a non-standard way of distributing Python software. As far as we know, there are no official standards or PEPs issued by the Python Software Foundation regarding bundling Python scripts with a Python interpreter into a standalone application, and as a result, there are no requirements that a Python binary extension must meet to be compatible with such bundling. The builders you mentioned (cx_Freeze, Pyinstaller) are third-party ‘Python-related’ tools (like hundreds of others) and we can’t give you any explanations on the compatibility of applications built by these tools with other elements of the Python ecosystem.

We recommend that you take the following steps:

  1. As we have explained before, the locating of a Python shared library during loading a Python binary extension is a common well-known issue on Linux and macOS systems. Our development team is constantly working to make the process of installing our Python extensions easier and more convenient. We expect a version of Aspose.Slides for Python via .NET with significant improvements regarding this issue to be released in April - May 2023. We think it would be reasonable for you to wait for this version and try again what you are doing with this version of Aspose.Slides for Python via .NET.

  2. If you’re still not successful, you might be wise to clarify whether the bundler you’re using actually supports bundling binary extensions or not in its documentation or customer support.

30

Is there an update/ETA on point 1? Thank you

31

@bowespublishing,
I requested information from our development team for you. We will let you know soon.

32

Any update please?

33

@bowespublishing,
I am still waiting for a response from our development team.

34

PS Aspose.Slides is pretty messed up on Mac. Please don’t pass the buck onto other software when the issue is with aspose only.

otool -L /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/aspose/slides.cpython-39-darwin.dylib 
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/aspose/slides.cpython-39-darwin.dylib:
	@rpath/slides.cpython-39-darwin.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libpython3.9.dylib (compatibility version 3.9.0, current version 3.9.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

It’s linked against itself for some bizarre reason and against a libpython with a hardcoded location /usr/local/lib/libpython3.9.dylib.

When PyInstaller runs on it, there will be two copies of libpython getting loaded - the one PyInstaller put in your application and the original one at /usr/local/lib/libpython3.9.dylib. macOS treats loading two copies of the same library as criminal and kills the process.

Reference - "zsh segmentation fault" with aspose.slides on MacOS · Issue #7570 · pyinstaller/pyinstaller · GitHub

35

I can confirm that your python library is linked against itself which is a very rookie mistake!! :joy: and as I said before a hardcoded location for libpython!! Screenshot 2023-04-15 at 20.27.15.jpg (260.4 KB)

36

@bowespublishing, @podycust,
Thank you for the additional information. I forwarded it to our developers.

37

any updates on this please?

38

It’s been over a month since the initial request for further information. Surely it can’t take that long to get even a basic response?

39

@podycust @bowespublishing

We still need time to investigate and fix the issue.

40

@podycust @bowespublishing

aspose.slides is a binary extension for Python and has its own requirements for the Python installation into which it can be installed. A Python installation with a separate Python shared library is required, but can be downloaded using the dlopen function. Sometimes this requires a Python configuration change or configuration of the macOS environment. Our requirements are explained here - follow these guidelines and we will be able to use aspose.slides in Python macOS.

In Q3 we’re going to be releasing major enhancements to the Python shared library auto-search, which will save users from having to manipulate macOS variables settings. Perhaps these improvements will solve your problem with PyInstaller.

Please note that: Aspose.Slides like the other Aspose binary extensions for Python are designed to be distributed using PyPI and wheels. PyPI and wheels - These are both Standard and Recommended ways to distribute the software. Unlike Bundles (such as the PyInstaller), which are neither the standard nor the recommended way to distribute Python software.