Matlab 2022b installer is unable to start on an OpenRC (non-Systemd Linux) system

Dear all,

Installer of Matlab 2022b first claimed that it cannot open a window.

Following answers on the Mathworks site and installing a few "missing" libraries (by running

./bin/glnxa64/QMATLABWindow

and installing the next missing one then re-running it) I quickly hit

error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory

I am stuck here as on my Gentoo box with OpenRC (rather than Systemd) as the init system I cannot simultaneously install systemd.

I would be greatful for helping me out. Thank you in advance,

Tamas

[Erich]

Does Gentoo provide libelogind.so.0?

Here is a solution for Slackware (also without systemd):

https://www.linuxquestions.org/questions/slackware-14/how-to-fake-libsystemd-so-for-matlab-r2022b-4175716955/

[Tamás Kárpáti]

Dear @Erich, thank you for your idea and the link. Yes, in Gentoo you may choose between OpenRC and Systemd. I chose OpenRC and thus I have libelogind.so.0 installed. Switching would, however, be quite a work (if possible at all due to many dependencies) which I cannot take for now.

I tried faking libsystemd.so.0 by symlinking which failed in a new way: the installer window opened up but could not populate it by "uicontrol"-s, just hanged up until the first hit by a CTRL+C -without a message (thus I could not identify further missing libs). Anyways, such symlinking is considered dangerous, I took the risk this time only and I recommend others not to do it.

According to the discussion you linked, the issue might be due to the Installer's (and MATLAB's) new hard dependence on the MATLAB Web App Server architecture. It is a pity as I neither need nor want that WAS.

I expect from the MATLAB developers to provide a workaround for non-systemd users and/or those who do not want the Web App Service. It would also be nice if the installer checked for available/missing libs before actually starting.

I'm looking forward for a solution or new ideas.

[Erich]

Hello Tamás,

As it worked for me, I must assume you're missing some other library then. Before I did the symlink trick, it looked like libsystemd.so.0 was the only missing library:

# ldd MATLABWindow | grep "not found"

libsystemd.so.0 => not found

And also I'll not I didn't create the libelogind.so.0 -> libsystemd.so.0 link in /lib64, rather I created the link in /opt/MATLAB/R2022b/bin/glnxa64 so the only affected software is MATLAB. (And also in the installer location so it could work properly.)

Have you tried using "ldd" to see which libraries the installer is looking for?

cd <installer_dir>/bin/glnxa64

ldd MathWorksProductInstaller

ldd MATLABWindow

Furthermore, one can use objdump to find out which specific symbols are required. I'm not going to go through every library, but we can see that one of the libraries MATLAB provides does depend on libsystemd:

objdump -xtT libdbus-1.so.3 | grep -i systemd

NEEDED libsystemd.so.0

required from libsystemd.so.0:

0x0562c8b9 0x00 06 LIBSYSTEMD_209

0000000000000000 DF *UND* 0000000000000000 LIBSYSTEMD_209 sd_is_socket

0000000000000000 DF *UND* 0000000000000000 LIBSYSTEMD_209 sd_listen_fds

Let's see if libelogind.so.0 (at least on my system) provides those symbols:

$ objdump -xtT /lib64/libelogind.so | grep sd_is_socket

00000000000562d0 g DF .text 0000000000000130 LIBSYSTEMD_209 sd_is_socket

00000000000567d0 g DF .text 000000000000016b LIBSYSTEMD_209 sd_is_socket_unix

0000000000056580 g DF .text 0000000000000250 LIBSYSTEMD_233 sd_is_socket_sockaddr

0000000000056400 g DF .text 000000000000017a LIBSYSTEMD_209 sd_is_socket_inet

$ objdump -xtT /lib64/libelogind.so | grep sd_listen_fds

0000000000055ed0 g DF .text 000000000000012a LIBSYSTEMD_227 sd_listen_fds_with_names

0000000000055dc0 g DF .text 000000000000010c LIBSYSTEMD_209 sd_listen_fds

Yep, it does. So no, in this case it's not dangerous to fake libsystemd.so.0 using libelogind.so.0. (To be fair I didn't go through and check every single library.)

Another thing you can try (which I didn't!) is if your system provides the same or newer system libraries (e.g. libdbus-1.so) you might be able to replace the MATLAB-provided system lilbraries with your own system libraries. This way it will drop the libsystemd.so requirement. (Neither MathWorksProductInstaller nor MATLABWindow directly depend on libsystemd.so - it's only the libraries they depend on that depend on libsystemd.so.)

[Erich]

So I was curious and went ahead and checked ALL libraries and execuatables in the installer and the MATLAB installation and it turns out the only library that directly depends on libsystemd.so.0 is libdbus-1.so.3.19.11:

# ./find_systemd_files.sh

********************************************************************************

./bin/glnxa64/libdbus-1.so.3.19.11

NEEDED libsystemd.so.0

required from libsystemd.so.0:

0x0562c8b9 0x00 06 LIBSYSTEMD_209

0000000000000000 DF *UND* 0000000000000000 LIBSYSTEMD_209 sd_is_socket

0000000000000000 DF *UND* 0000000000000000 LIBSYSTEMD_209 sd_listen_fds

And here are my scripts that did the checks:

# cat find_systemd_files.sh

#!/bin/bash

find . -type f -exec ./examine_file.sh {} \;

# cat examine_file.sh

#!/bin/bash

if ! file "$1" | grep -q "ELF 64-bit LSB shared object\|ELF 64-bit LSB executable" ; then

exit

fi

if objdump -xtT "$1" 2>/dev/null | grep -q -i libsystemd ; then

echo "****************************************************************************

****"

echo "$1"

objdump -xtT "$1" | grep -i libsystemd

fi

The question I cannot answer is if the functionality that libsystemd.so.0 provides (and libelogind.so.0 also provides those same needed symbols) to libdbus-1.so is in turn required by MATLAB. Those two functions (sd_is_socket and sd_listen_fds) that libdbus-1.so requires are provided by libelogind.so.0, as I've already mentioned, so actually it doesn't matter if they are required or not. Faking libsystemd.so.0 using libelogind.so.0 is not only not dangerous, it is the correct solution.

[Tamás Kárpáti]

Dear @Erich, thanks for your efforts you have put into this issue :)

It is a great idea and useful approach. Tried your script with the same result.

In my case it does not matter wether I put the fake symlink in /opt, /lib64 or the bin/glnxa64 folder. Finally I followed your yet-another idea: simply made bin/glnxa64/libdbus-1.so.3 (symlink) point to my system libdbus which is newer and -most importantly- was not built against libsystemd.so.0.

The installer is still failing, so I will use your approach to test all executables/libraries for missing dependencies and fullfill requirements. On a Gentoo box you're able to specify inter-package dependencies via USE flags, so I might need not only install missing packages but also to recompile several existing packages with altered USE flags.

One more interesting observaton: the difference between system and installer dependencies:

ldd /usr/lib64/libdbus-1.so.3.32.0
    linux-vdso.so.1 (0x00007ffded2ec000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fac394a1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fac39711000)

and

ldd bin/glnxa64/libdbus-1.so.3.19.11
    linux-vdso.so.1 (0x00007fff75ae0000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5353ae1000)
    libsystemd.so.0 => not found
    libc.so.6 => /lib64/libc.so.6 (0x00007f53538e4000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5353b5e000)

Thank you so far. I'll report the solution if ever getting there. Best regards, t

[Erich]

Interesting. Here is Slackware's libdbus-1.so for additional information:

# ldd /usr/lib64/libdbus-1.so.3.19.13  
linux-vdso.so.1 (0x00007ffde2985000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe24c102000) 
libelogind.so.0 => /lib64/libelogind.so.0 (0x00007fe24c058000) 
libc.so.6 => /lib64/libc.so.6 (0x00007fe24be79000) 
/lib64/ld-linux-x86-64.so.2 (0x00007fe24c1db000) 
libcap.so.2 => /lib64/libcap.so.2 (0x00007fe24be6c000)

Most (all?) official Slackware packages (it is a binary distrubution unlike Gentoo) are compiled on an already-existing full Slackware installation, which means optional dependencies often get pulled in as long as they're part of a full Slackware installation.

[Tamás Kárpáti]

Started to script an automatical replacement of all symlinks (to hundreds of libs) in bin/glnxa64 to existing system libs but quickly realized that I've got to do my job -which is something else. I think an all-replace would probably work (from the user side) but (i) unsure about this and (ii) I'd rather wait for MATLAB developers prepare a correct solution (a rebuild with -optionally- less dependencies).

It's nice to know that Slackware is so open that can provide OpenRC even being a binary distro :)

[Erich]

You can try opening a support ticket, but I doubt you'll get much help. Several years ago I found that there was a requirement on libpam.so (at the time Slackware shipped without PAM).

Here is part of their response:

Thank you for contacting MathWorks. Unfortunately, Slackware is not a qualified distribution for running MATLAB. This means we do not test or verify that the software runs on Slackware, and our ability to troubleshoot and provide support for the platform may be limited.

You may be able to install the PAM library through a third-party package created for Slackware.

Alternatively, any of our qualified Linux distributions are known to run R2017a without issue.

I solved the issue by compiling the PAM libraries and copying libpam.so into my MATLAB installation directory.

[Tamás Kárpáti]

Dear @Erich, once again I thank you your efforts (tips, experiments & explanations :)

Today got a message from the local reseller, they might be working out a solution (awaiting their answer), though I guess the installer (and probably MATLAB) needs a rebuild with less dependencies. Will be back to report what conclusion was reached.

[Tamás Kárpáti]

Updates:

1, Removing all installer libs that are present in the system and adding their path to LD_LIBRARY_PATH did not help.

2, The latest MATLAB version that installs and works on my system (without any tempering) is R2021a.

3, Still waiting for tips from the local reseller.

Will let you know if a solution is found.

[Joseph Young]

I just went through this with my system. It appears as though R2022b bundles its own version of libdbus-1.so.3 whereas R2022a uses the system version. The bundled version of libdbus-1.so.3 depends on the system's version of libsystemd.so.0, which is not present on OpenRC based systems. The simplest method to resolve this issue is to preload a working system version of libdbus-1.so.3, which doesn't necessarily require systemd. For example, the following command works on my system:

LD_PRELOAD=/usr/lib64/libdbus-1.so.3 ./bin/glnxa64/MATLABWindow

Running the installer with the same preload worked for me.

[Tamás Kárpáti]

Dear Joseph,

Thanks for your suggestion. I also tried this with both libdbus-1.so.3 and libstdc++.so.6 added to LD_PRELOAD to no avail. I'm not sure if LD_PRELOAD is space separated but finally it is not even necessary if I first remove the symlinks in bin/glnxa64 and then recreate them so that they point to the system files. Thanks for confirming. I'm happy for it works for you.

[Joseph Young]

I'm glad to hear that you have a solution that works. Originally, I did the same as you and just fixed the symbolic links and that worked for me as well. I'll also mention that I override libstdc++ the same as you. As far as LD_PRELOAD, in bash, this is a list separated by colons. Therefore, my command line becomes:

LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6:/usr/lib64/libdbus-1.so.3 matlab

This can be added as an alias in .bashrc with something like

alias matlab='LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6:/usr/lib64/libdbus-1.so.3 matlab'

As one more alternative, the actual executable itself can be patched using patchelf to replace the location of these libraries.

In other words, there are at least three ways to fix the problem: change the symbolic links, LD_PRELOAD, or patchelf. Anyway, it looks like you have something that works. Mostly, I'm trying to relay this information since it looks like this is the only location for such documentation and I don't think we're the only people running into this issue.

[Tamás Kárpáti]

Such a colon separated file list looks unique (typically file lists are space, path lists colon separated). Thanks for the info! Unfortunately the installer issue is not yet solved but I will summarize when a solution is found.

You mentioned "pathelf". What does it mean?

[Joseph Young]

The utility patchelf is a utility for modifying ELF executables, which is the typical executable format under Linux. You can find a man file for it here. Most distributions have a version or at least one that can be installed. Basically, it's one way to modify where an executable looks for its shared libraries. To be clear, if LD_PRELOAD or changing the symbolic links doesn't work, it's not clear to me patchelf will either, but your mileage may vary.

Alternatively, Mathworks could revert to using the system version of libdbus-1.so.3 rather than bundling it, which would fix both of our problems. This is what R2022a appears to do. Though, they may have their own internal reasons for doing so.

[Tamás Kárpáti]

I agree. Thanks for the info.

[Miles Malone]

A workaround on openrc or any other init systems where you've got elogind installed is to symlink libelogind.so.0 to libsystemd.so.0 as they both provide the symbols MATLABWindow is looking for. So symlink /lib64/libelogind.so.0 to /path/to/matlabInstallFiles/bin/glnxa64/libsystemd.so.0, and run install as per normal

[Tamás Kárpáti]

Dear Miles, thanks for your suggestion. I have came across this one and found out that it is unnecessary, as only libdbus depends on libsystemd and thus only replaced libdbus-1.so.3 first. Currently I'm also replacing libstdc++.so.6 and libjawt (plus libpython3.8.so.1.0).

Let me update the current situation for those who are interested:

I'm still in contact with the supporting team and the install process was lately done via the "silent install" method. MATLAB itself is not yet running. I will update when obtain a working MATLAB. On the other hand, it does not seem to be an OpenRC issue anymore but the origin is still not clear.

Answer 1

[Tamás Kárpáti]

Dear all,

The issue has been solved today, thanks to the Mathworks support and the local Gamax Laboratory Solutions in Hungary. Along the time the issue looked more and more complicated but looking back it is quite straightforward to solve. To summarize the general workflow of installing MATLAB under Linux if a failure (and error messages) are hit:

1, Install software dependencies -as suggested by the error messages (in my case libselinux and nss-utils).

2, Add necessary features to installed dependencies (from errmsgs, too, in my case Vulkan support to qtgui, libsdl2 and mesa, experimental features to Harfbuzz and an up-to-date set of graphics card drivers -binary blobs in my case).

3, Replace libraries (*.so* files) of the MATLAB Installer by symlinks to system provided ones (libdbus-1.so.3 --> /usr/lib64/libdbus-1.so.3 and libstdc++.so.6 --> /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6 ... the Systemd dependence is hidden in these implicitely; try to use ldd and objdump as above).

4, Perform the installation (if still fails, follow the "silent method" or "silent installation" -for me only this worked).

5, Replace MATLAB-installed libraries (*.so* files) by symlinks to system provided ones (in my case the above two plus libpython3.8.so.1.0 --> /usr/lib64/libpython3.10.so.1.0 as outdated and libjawt.so --> /opt/openjdk-bin-17.0.3_p7/lib/libjawt.so).

This way I got rid of every error messages.

In my case MATLAB still failed to start up normally, as I got a blank (white) unresponsive window waiting endlessly. It turned out that MATLAB tried to get a license file (license.lic) but could not. The SOLUTION was to DOWNLOAD it from the Mathworks site AND PROVIDE it through the -c command line option, like

$ matlab -c ~/license.lic

Now MATLAB has just started to work for me. Last few hours I already noticed some further minor library issues that I think will be possible to solve as in 3, but anyways, the aboves give a working solution for now.

Note that in this case the -c option is necessary for even the -nodesktop or -h run.

Thanks a lot for all who answered here and out there at Gamax and Mathworks!

The issue is now closed.