Arch Linux User Repository

So after chowning /opt/MATLAB to my user so I can install addons, I am getting the same issue as @AnonymePalme when trying to use Simulink. It complains about what seems to be QNetworkAccessManager::ignoreSslErrors missing from the system's Qt5?

The following error is retyped by hand because MATLAB doesn't let me highlight and copy paste from the error box; there might be typos:

Can't load '/opt/MATLAB/R2025a/bin/glnxa64/libmwdastudio.so', this error is normally caused by a missing or mismatching library from the dependency chain of the named library.
Details: 'Error loading /opt/MATLAB/R2025a/bin/glnxa64/builtins/shared_dastudio_builtins/mwdastudio_builtinimpl.so.
/opt/MATLAB/R2025a/bin/glnxa64/builtins/shared_dastudio_builtins/../../../../bin/glnxa64/libmwglee2_qt.so:
undefined symbol:
_ZN21QNetworkAccessManager15ignoreSslErrorsERK5QListI9QSslErrorE, version Qt_5: No such file or directory: No such file or directory'

I got the 5201 error mentioned earlier, so decided to give up and try changing the version of the package back to R2025a. It works now, but add-ons menu doesn't even though I have now installed java-matlab.

Warning: Unable to find Java library: /opt/MATLAB/R2025a/java/lib/server/libjvm.so
Please check if you have a MATLAB_JAVA environment variable.
Note that MATLAB requires Java version 1.8 or higher.

If I look at the java-matlab package contents, there's no libjvm.so, or even java/lib at all. Am I supposed to do some other step

EDIT: I think I have everything working now. I don't remember the exact steps I did, but I do remember gtk2 being a hard dependency of everything. Then I was able to do the patchelf command after running and crashing matlab, use product authorizer somewhere along the line, and I can run 2025b. I also fixed the add-on store by manually selecting the openjdk-8 I have installed in the settings for the JRE path in matlab. I also chown'd /opt/MATLAB to my user so I could install add-ons. Is there a better way to be able to have write access to the MATLAB folder/

Hello fellow Matlab users, I had the Issue that Matlab installed by this script is shipping an incomplete Qt stack which resulted in simulink crashing, I could fix this by coping libQt5* to /opt/MATLAB/R2025b/bin/glnxa64 from the unzipped matlab R2025b install folders /bin/glnxa64 might be nice to include it, with this small fix I now got a fully working matlab/simulink from this package thanks for your work

@kyak,

This is a strong claim to make. You should better be in contact with MathWorks support regarding your error:

I thought that as the expert on MATLAB who clearly understands MATLAB and knows what they are talking about, you would know that you are supposed to also submit OS info in the support ticket, which will immediately make the case invalid since Arch is unsupported.

You clearly don't understand that MATLAB, in fact, downloads a bunch of libraries and executable files and runs them as part of so called "MATLAB Service Host". This thing also updates itself (which is what probably happened). So no, the client sides changes, and does that without your intervention.

I clearly said SYSTEM updates?.. I did not update my system, so the breakage is not related to SYSTEM updates. Does that not make sense? I am well aware of the libraries MATLAB stores in $HOME, the package even instructs you to patch one of them. And yes, I did play around with those.

But please refrain from doing this unless you know what you doing (which you don't).

I thank you for your immense input, and please refrain from commenting on any of my packages in such a tone ever again!

Based on this, it appears MathWorks is now blocking unsupported operating systems through a license server check.

This is a strong claim to make. You should better be in contact with MathWorks support regarding your error:

Unable to communicate with required MathWorks services (error 5201).

The breakage is not related to client-side system updates. Everything was working on 2025-09-27, but on 2025-09-28, with no changes to the system or the license, it stopped working.

You clearly don't understand that MATLAB, in fact, downloads a bunch of libraries and executable files and runs them as part of so called "MATLAB Service Host". This thing also updates itself (which is what probably happened). So no, the client sides changes, and does that without your intervention.

Also, it was interesting to read your convoluted ideas about packaging individual toolboxes and messing with appdata. But please refrain from doing this unless you know what you doing (which you don't).

Running MATLAB in a container is a way moving forward. This is a beast with magnitude of dependencies. You will eventually find yourself in a situation when two functionalities of MATLAB won't work at the same time because of conflicting libraries needed for each of them (e.g. S-Function/mex files compilation will work from command line, but not when using C Function block in the model).

Not to mention that you must trust MathWorks way too much to allow the above mentioned MATLAB Service Host run all the time (it runs even after exiting MATLAB) and update itself in unattended manner outside of container.

I am not having any issues with R2024b on a fully updated daily driver (not a clean chroot by any stretch of the imagination) after I dealt with the gnutls issue. I am on a perpetual standalone license.

If network licenses run in a systemd-nspawn, I am not sure what the license server could be blocking on. It cannot be the kernel or init/systemd version since those are shared in nspawn containers. If it was me, I would spin up a Debian Sid container and see if it works there or use the Arch archives to go back to 2022/2023 which should roughly match Ubuntu 22.04

After spending a few days trying to find the root cause, I have gathered the following points:

1. The breakage is not related to client-side system updates. Everything was working on 2025-09-27, but on 2025-09-28, with no changes to the system or the license, it stopped working.

2. The breakage is not related to client-side package updates. I downgraded to a cached R2025a release and encountered the same error. I also tried generating packages and manually installing older releases (R2025a, R2024b, R2024a, ...) and all of them failed with the same error. Some of the older releases do not have ABI mismatch problems, which rules those out.

3. The breakage is not related to gnutls, libstdc++, libtiff, or any other previously known issues, including execstack. I tested different versions of these libraries and different package releases, and the problem remained.

4. The breakage does not crash the application or the license server. In the past, MATLAB would crash and provide a stack trace and other details. This time it simply exits with an error code and no (public) instructions for fixing it.

5. The breakage behaves exactly like a damaged license server. Previously, the package broke after an update due to execstack issues, which required manually patching the license server library. That only worked when patched after installation and activation. When I attempted to patch it automatically in the PKGBUILD, I received the same error seen now.

Based on this, it appears MathWorks is now blocking unsupported operating systems through a license server check. This looks like another case of DRM causing unnecessary problems. For now, Arch users may need to use VMs, containers, systemd-nspawn, or other workarounds to make it run. If the next release (R2026a) is also broken, it will be reasonable to assume this will never work legally, and I will request that this package be deleted. It was a good run, and I thank everyone who contributed.

@kyak, that systemd-nspawn (MATLAB in a container) method seems convoluted, but a bit more futureproof than the package. Thanks for sharing it. (I wish MathWorks took on source distribution (Arch/Gentoo/Nix) support instead of only supporting Debian/RHEL-based distros.)

Hi fellow MATLAB users,

After spending years fixing breakages in MATLAB following Arch updates (which often came in as a surprise), I'm happily running MATLAB in systemd-nspawn now.

It doesn't take much time to get it up and running, see https://wiki.archlinux.org/title/MATLAB#MATLAB_in_a_systemd-nspawn

The last time I updated this piece of wiki was around R2021b, but it's mostly the same as of R2025b.

greetings, i found my typo and tried again. i got the same error as you.

but thank you alot!