Arch build of libreoffice fails in subtle ways if started from a terminal where a python virtual environment is active
Description:
The arch build of Libreoffice fails in subtle ways when started from a terminal where a python virtual environment is active.
This does not happen using the binaries from the Document Foundation that are available via AUR packages.
The reason for the different behavior is that the upstream binaries embed a python runtime and assure that such runtime is used from Libreoffice. Conversely, the Arch build is compiled against the system Python, but does enforce that such python is actually employed when Libreoffice is started. This means that if a python virtual environment is active, Libreoffice will try to work with a python that is different from what it expects and may fail.
The failure may happen in rather unpredictable ways, depending on various things: (i) the skew between the system python and the active virtual env python; (ii) whether you have or not Libreoffice extensions installed that are python based; and possibly more.
A frequent symptom is Libreoffice saying: 'std::bad_alloc' before crashing.
The issue is nasty because of the variability of the error condition and error messages that appear misleading, making one think that the problem is with the application.
To fix the issue, I think that it would be enough to ensure that Libreoffice uses the system python.
Additional info:
- package version(s): 25.2.1.2 520(Build:2)
- config and/or log files: Not relevant
- link to upstream bug report, if any: N/A
Steps to reproduce:
- set up a python virtual environment with a python interpreter different from the system one (e.g. using
uv). - activate the environment
- start libreoffice from the command line