Arch Linux User Repository

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!

Never mind, MATLAB is broken for me again. It was working just yesterday, but as of today I'm getting this during initialization:

$ matlab -desktop
Unable to communicate with required MathWorks services (error 5201).


For help with this issue, contact support: 
https://www.mathworks.com/support/contact_us.html


Unable to launch MVM server: License Error: Licensing shutdown

The error is exactly the same as when I tried to patch execstack during build() instead of asking the user to do it manually. Again, it still launches with root privileges (sudo matlab -desktop). I've checked all *.so files, and none of them have execstacks now, even without patching. Also, glibc has been updated to 2.42, which was supposed to fix any issues with execstacks. MathWorksProductAuthorizer works just fine, so it doesn't look like a gnutls issue to me.

If anyone is able to find a solution, I would be grateful.

Package updated to R2025b.

Apologies for not being able to help here for a while. The bad news is that R2025b still targets ubuntu24.04 / ubi9, which means it inherits all the same problems as R2025a. The good news is that all the issues I'm aware of are now covered by the package.

@Fitti, @britin, I was able to reproduce the issue by not activating MATLAB before launching it. Please read the post-installation instructions more carefully next time, you only ran one of the two required commands.

@bbaovanc, the "APPS / Get More Apps" menu (among others) requires java-matlab to be installed to function properly.

@vicious, you have an extra f at the end of the file name.

@daniel_shub, thanks for the information. Packaging (and honestly, even just using) MATLAB is a huge pain, and unless someone specifically requests an older release, I won’t be spending weeks of effort to support it.

Regarding the toolboxes: the days of matlab.fic and matlab.lic are long gone. The last release to support that method was R2023a. Everything since then can only be installed non-interactively using MPM, or via an .iso for a selected license (which I don't have access to).

That said, this isn’t really the core issue. I was able to write a script to split a product based on the files stored in appdata/. It took quite a bit of effort, there’s no public documentation, and some files overlapped between products. This forced me to create helper scripts and hooks to back up and merge shared files. While MATLAB did recognize the products as installed, it didn’t provide any menu options to launch them. I suspect some kind of service registration is required, but I wasn’t able to reverse-engineer that part. And even if I had, most products have shared components that overlap, which makes this style of packaging even more complex.