Page MenuHomePhabricator
Create Task
Maniphest T27894

Linux nightly installer doesn't start on Fedora
Closed, DuplicatePublic
Actions

Description

Taking the nightly installer for Ubuntu 20.04 from the Jenkins workspace and launching it on Fedora 32 fails while initializing Python:

[2.468] Initializing python service
terminate called after throwing an instance of 'mitk::Exception'
  what():  /home/ubuntu/jenkins-agent/MITK/Nightly/Ubuntu20.04/src/MITK/Modules/Python/autoload/PythonService/mitkPythonService.cpp:68:
Python runtime could not be loaded: /usr/lib/x86_64-linux-gnu/libpython3.8.so: cannot open shared object file: No such file or directory

The reason is a different path for the libpython3.8.so on Fedora. One solution could be to strip the absolute path before the dlopen call, this should cause a search in the usual library locations.

We could also decide this is a known issue, but still take it as a reminder to specify compatibility of Linux binary installers somewhere.

Related Objects
Search...

StatusAssignedTask
 OpenNoneT27196 Rewrite packaging of MITK
 DuplicateNoneT27894 Linux nightly installer doesn't start on Fedora

Event Timeline

nolden created this task.Oct 19 2020, 1:07 PM
nolden edited projects, added MITK (v2021.02); removed MITK.
kislinsk added a subscriber: kislinsk.Oct 19 2020, 1:18 PM

I guess this is not specific to Fedora (not even to Linux) as we do not yet package python into the installer as far as I know. As this task is a bit moe vorbose than T26258: MITK and python only works with the specific python version the installer was created with, I will close the other one as duplicate.

kislinsk triaged this task as Normal priority.Oct 19 2020, 1:18 PM
kislinsk merged a task: T26258: MITK and python only works with the specific python version the installer was created with.
kislinsk added a parent task: T27196: Rewrite packaging of MITK.
kislinsk added a subscriber: neher.
nolden added a comment.Oct 19 2020, 1:25 PM

I was just about to add a note that there is the general question how to handle python in installers. I guess for just having the basic runtime available it would be ok to just load libpython3.so or libpython3.8.so and let the system take the right one from the right path. But on Windows I guess most people don't install Python in system locations. Anyway I think this could be fixed even with the current packaging if we need it for 2020, but I'm just reporting, no pressure from my side ;)

kislinsk added a comment.Oct 19 2020, 1:44 PM

Agree, but we should definitely package Python instead of relying on system python in any case as there are more strings attached. Even between minor Python updates there are imcompatibilities especially when SWIG is involved. Also we rely on certain Python packages like numpy or SimpleITK. So the plan is:

  • It's okay to use system python during development
  • But it will be packaged (including the necessary site packages) into installers
kislinsk closed this task as a duplicate of T27693: Packaging Python does not work/is not implemented.Jan 15 2021, 12:09 PM
MITK · MIC · IMSY · DKFZ