Arch Linux User Repository

Weird, for me when I run matlab_jenv system or matlab_jenv -allusers system, it says:

Unable to locate Java "system" version

Download and install a supported version of Java. For more information 
 https://www.mathworks.com/support/requirements/language-interfaces.html 

Alternatively, to use the MATLAB-provided JRE, type: 
 matlab_jenv factory 

I can't remember a point where it ever worked for me, even about a month ago when I was first trying it. I have a lot of JDKs installed, so there should be plenty to choose from, unless that's part of the problem?

$ pacman -Qs jdk 
local/jdk-openjdk 25.u36-1
    OpenJDK Java 25 development kit
local/jdk11-openjdk 11.0.28.u6-1
    OpenJDK Java 11 development kit
local/jdk17-openjdk 17.0.16.u8-1
    OpenJDK Java 17 development kit
local/jdk8-openjdk 8.462.u08-1
    OpenJDK Java 8 development kit
local/jre8-openjdk 8.462.u08-1
    OpenJDK Java 8 full runtime environment
local/jre8-openjdk-headless 8.462.u08-1
    OpenJDK Java 8 headless runtime environment

@bbaovanc, thank you for taking the time to look into this. Unfortunately, I’m still not able to get it to work. As I’ve already mentioned, patchelf should no longer be relevant, since the new license server doesn’t seem to suffer from this issue. I also had gtk2 installed both before and after the breakage, and that doesn’t seem to help either.

About a week ago, I reinstalled MATLAB in the hope of getting it to work, and I was able to do so by running:

find "/usr/lib/gnutls3.8.9" -maxdepth 1 -type f,l -name 'lib*.so*' -exec \
    ln -vsf {} ~/.MathWorks/ServiceHost/-mw_shared_installs/v*/bin/glnxa64/ \;

The v* expression expanded to something like v2025.10.*.* (I don’t remember the exact version). Interestingly, after activating, crashing, and patching the execstack, the usual login asked me to confirm my email by redirecting me to https://www.mathworks.com/mwaccount/widgets/embedded/profiles/verify/confirm, which had never happened before. I then tried to reproduce the behaviour to confirm that I’d found the root cause, but after that, the expression only expanded to v2025.8.1.1, and I wasn’t able to “update” it. Still, this confirms that Arch itself isn’t blocked, which is very good news.

Regarding Qt5, I used to remove the bundled runtime to make it work on Wayland without extra tinkering, but as you and @AnonymePalme reported, this causes issues, so I’ve stopped removing any runtimes. We’re now using matlab-meta and java-matlab-meta to pull in the dependencies, just like before I took over maintenance.

As for Java, I’m removing the bundled JDK in favour of the system-wide one. MATLAB actually supports this natively. The java-matlab package also includes a .hook and an .install file to correctly set the JDK. For me, this works even with a broken license server:

$ matlab_jenv
JavaEnvironment with properties 
Version       : openjdk version "17.0.16" 2025-07-15
                OpenJDK Runtime Environment (build 17.0.16+8)
                OpenJDK 64-Bit Server VM (build 17.0.16+8, mixed mode, sharing)
Home          : /usr/lib/jvm/java-17-openjdk 
Library       : /usr/lib/jvm/java-17-openjdk/lib/server/libjvm.so
Configuration : system 

$ pacman -Qs jdk
local/jdk17-openjdk 17.0.16.u8-1
    OpenJDK Java 17 development kit

Before the breakage, this setup had always worked for me, including for the Add-on Store. Could you please show your output?

Also, regarding Simulink, is there a reason you install it with chowns and the Add-on Store instead of enabling the product in the PKGBUILD?

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.)