Package Details: matlab-gcc12 1:R2025b+25.2.0.2998904-2

Git Clone URL: https://aur.archlinux.org/matlab.git (read-only, click to copy)
Package Base: matlab
Description: A high-level language for numerical computation and visualization (GCC12 runtime dependency)
Upstream URL: https://www.mathworks.com/products/matlab.html
Keywords: computation matlab numerical visualization
Licenses: custom:MATLAB EULA
Conflicts: matlab-gcc, matlab-r2025b-gcc
Provides: matlab-gcc, matlab-gcc-release, matlab-gcc-version, matlab-r2025b-gcc
Submitter: ido
Maintainer: vitaliikuzhdin
Last Packager: vitaliikuzhdin
Votes: 41
Popularity: 0.113310
First Submitted: 2015-08-15 09:33 (UTC)
Last Updated: 2025-09-27 20:52 (UTC)

Dependencies (6)

Required by (1)

  • matlab (requires matlab-gcc) (optional)

Sources (1)

Pinned Comments

vitaliikuzhdin commented on 2025-09-30 19:38 (UTC)

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.

vitaliikuzhdin commented on 2025-07-16 13:12 (UTC) (edited on 2025-08-05 20:05 (UTC) by vitaliikuzhdin)

TODO:

  1. Figure out the users and permissions. Currently, /opt/MATLAB/${_release} has 777 permissions, which is obviously undesired. It might be better to create a user group and require users to manually add themselves to it for security reasons.

  2. Improve the installer. For example, the current inotify watcher spams stdout and does not account for the end of the download/installation or the width of the terminal, which results in flaky output.

  3. Figure out the dependencies. The list of Debian/RHEL dependencies is public, but it includes some seemingly unneeded packages. This might be because they are required by dependent products/add-ons. Additionally, the current logic for removing bundled dependencies should probably be rewritten. Maintaining an exhaustive list for a single release is very difficult, and these components change without notice. Moreover, the current approach may go against the Arch KISS philosophy. Ideally, we should remove only the problematic components like Qt, XCB, libtiff, gcc-libs, fontconfig, etc.

  4. Add auto-discovery for packages written for MATLAB. My plan was to use /usr/lib/MATLAB/${_release} for release-specific modules and /usr/lib/MATLAB/common for shared (mostly architecture-independent) packages. However, load order matters, and "common" modules need to specify which releases they are compatible with. This means we need to implement our own logic for discovering and loading these, likely via hooks, shell scripts, and configuration files (perhaps TOML could work?).

  5. Fix the Python components. python-matlabengine does install the Python components built against the version of Python shipped by Arch. However, some proprietary CPython components are not included and are built against ancient Python versions. This likely requires version spoofing or some alternative approach.

  6. Write and upload packages for previous MATLAB releases. It is entirely possible to have multiple releases installed simultaneously. I have a few of these packages myself, but they are drafts and not suitable for upload to the AUR.

  7. Write and upload packages for MATLAB-dependent add-ons and products. When installing MATLAB required user intervention for source access, it was acceptable to break reproducibility and manually specify required products for installation. Now that we use MPM, it would be better to separate products into individual packages. These packages would install themselves and their dependencies into a specific location, then use appdata to install only the component's files. The problem is that MATLAB often includes conflicting files that need to be combined or overwritten. Obviously, we can't allow that, so a hook must be implemented to, for example, combine *.combine@matlab-simulink and replace *.replace@matlab-documentation files with backups. Needless to say, this is challenging to implement, so the previous approach (having users specify the product list) might still be preferred.

  8. Write and upload the matlab-runtime package. I have a draft, but the problem with this package is that it installs the runtime for every available product. Ideally, for source-built packages, we would want to makedepend on matlab-$product and depend on matlab-$product-runtime. However, this is not possible without splitting the runtime packages, which poses the challenges described above. I’ll try my best to revisit this sometime later.

vitaliikuzhdin commented on 2025-07-16 12:55 (UTC)

@aoneko, @Reexys, please read the post-installation instructions. If you've lost them, you can find the same information here.

Latest Comments

1 2 3 4 5 6 .. 29 Next › Last »

vitaliikuzhdin commented on 2025-10-01 09:44 (UTC)

@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!

kyak commented on 2025-10-01 03:53 (UTC)

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.

daniel_shub commented on 2025-09-30 21:03 (UTC)

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

vitaliikuzhdin commented on 2025-09-30 19:38 (UTC)

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.

ido commented on 2025-09-29 05:42 (UTC)

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

kyak commented on 2025-09-28 15:16 (UTC)

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.

vicious commented on 2025-09-28 12:37 (UTC)

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

but thank you alot!

vitaliikuzhdin commented on 2025-09-28 12:30 (UTC)

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.

vitaliikuzhdin commented on 2025-09-27 20:57 (UTC)

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.

tree_yang commented on 2025-09-27 09:38 (UTC)

MATLAB R2025a crashed on my machine everytime when I tried to use parpool. I have tried the solution provided by @bbaovanc, but it did not work. However, after I replaced "gnutls-3.8.9-1-x86_64.pkg.tar.zst" by "gnutls-3.8.8-1-x86_64.pkg.tar.zst", it worked successfully.

1 2 3 4 5 6 .. 29 Next › Last »