Arch Linux User Repository

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.

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

@vitaliikuzhdin I am just reading your pinned message now. As for your points 6 and 7, there might be some useful tidbits in my original AUR4 upload (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=matlab&id=54a6fe5c2e92bcb3b781aa58d50ccaa473de0e90)

I think pre-AUR4, I had different packages for each version, but those commits seem to be lost to history. The first AUR4 upload supported multiple versions, but I dropped that support since it was hellish to maintain.

In terms of packaging the toolboxes separately, years ago when there was a fik and a lic, I could never get this to work properly. If you are going to try and package the add ons separately, you really need multiple licenses so you can see what happens for a shared machine that has multiple users with multiple licenses. That is no small feat.

i get this after running the postinstall script:

~ ✗ sudo patchelf --clear-execstack ~/.MathWorks/ServiceHost/-mw_shared_installs/v*/bin/glnxa64/libmwfoundation_crash_handling.sof
patchelf: getting info about '/home/eric/.MathWorks/ServiceHost/-mw_shared_installs/v*/bin/glnxa64/libmwfoundation_crash_handling.sof': No such file or directory

I want to install Simulink. So, I tried to use the addons menu. But I am getting an error:

Error using matlab.internal.addons.UiMessageHandler
Error: File: UiMessageHandler.m Line: 373 Column: 20
Unable to find or import 'com.mathworks.addons_common.notificationframework.InstalledAddOnsCache'. Imported names
must end with '.*' or be fully qualified.

Error in matlab.internal.addons.Explorer (line 31)
            uiMessageHandler = matlab.internal.addons.UiMessageHandler(matlab.internal.addons.Explorer.SERVER_TO_CLIENT_CHANNEL);
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in matlab.internal.addons.Explorer.getInstance (line 42)
                obj = matlab.internal.addons.Explorer();
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in matlab.internal.addons.launchers.showExplorer (line 180)
        if matlab.internal.addons.Explorer.getInstance.windowExists
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Anyone know what to do about this?

I ran into the gnutls issue listed below as well. Attempting to use MathWorksProductAuthorizer would just instantly segfault. Because I had to scroll way down to find it, and the MATLABPATH there was wrong, I'm going to reiterate what I did which worked for me:

$ MATLABPATH=/opt/MATLAB/R2025a/bin/glnxa64/
$ GNUTLSPATH=/tmp/gnutls-3.8.9-1-x86_64.pkg
$ wget https://archive.archlinux.org/packages/g/gnutls/gnutls-3.8.9-1-x86_64.pkg.tar.zst
$ mkdir -p "${GNUTLSPATH}"
$ tar -xvf gnutls-3.8.9-1-x86_64.pkg.tar.zst -C ${GNUTLSPATH}
$ sudo mkdir "${MATLABPATH}"/gnutls
$ sudo cp -a "${GNUTLSPATH}"/usr/lib/* "${MATLABPATH}"/gnutls/
$ cd "${MATLABPATH}"
$ sudo ln -s gnutls/* ./

Does anyone have any updates per @Fitti 's issue? I am still having the same identical stack trace that he is having. For reference, I will post it here as well. I have tried the execstack/patchelf commands on the usual suspects per the comments here and on other arch forum posts. I can ask there if they may be of more help.

It is also to note that this stared after authorization, as the stack trace would obviously suggest. Before this, the fixes to the gnutls package that was posted earlier worked like a charm and the app will fully launch, however the editor/command line would not work as I was not authorized. Only after running the authorization does it give the instant crash seen here.

--------------------------------------------------------------------------------
          Segmentation violation detected at 2025-08-29 11:25:19 -0500
--------------------------------------------------------------------------------

Configuration:
  Crash Decoding           : Disabled - No sandbox or build area path
  Crash Mode               : continue (default)
  Default Encoding         : UTF-8
  Desktop Environment      : Hyprland
  GNU C Library            : 2.42 stable
  MATLAB Architecture      : glnxa64
  MATLAB Root              : /opt/MATLAB/R2025a
  MATLAB Version           : 25.1.0.2973910 (R2025a) Update 1
  Operating System         : Linux 6.16.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Aug 2025 19:49:53 +0000 x86_64
  Process ID               : 108462
  Processor ID             : x86 Family 6 Model 140 Stepping 1, GenuineIntel

Fault Count: 1


Abnormal termination:
Segmentation violation

Current Thread: 'MCR 0 interpret' id 140022774757056

Register State (from fault):
  RAX = 0000000000000000  RBX = 00007f5997bfcd88
  RCX = 00007f5a3da3bcc0  RDX = 00007f5a3da130c0
  RSP = 00007f5997bfccf0  RBP = 00007f59951fe0e0
  RSI = 0000000000001000  RDI = 0000000000000000

   R8 = 00007f5a3da39f20   R9 = 00007f5a3da39fa0
  R10 = 00007f5a3da10080  R11 = 00007f5a3da100e0
  R12 = 0000000000000000  R13 = 00007f5997bfcd10
  R14 = 00007f5997bfcd20  R15 = 0000000000000000

  RIP = 00007f5995241ae8  EFL = 0000000000010246

   CS = 0033   FS = 0000   GS = 0000

Stack Trace (from fault):
[  0] 0x00007f5995241ae8 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+02366184 lc_new_job+00000216
[  1] 0x00007f599515ccaf /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01428655
[  2] 0x00007f599515d735 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01431349
[  3] 0x00007f59951c70f4 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01863924
[  4] 0x00007f599515fb56 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01440598
[  5] 0x00007f599515e57d /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01435005
[  6] 0x00007f599518edc0 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01633728
[  7] 0x00007f599471a437 /opt/MATLAB/R2025a/bin/glnxa64/authz/licensing/product/matlab_impl/mwlicensingproductmatlab.so+00160823
[  8] 0x00007f5a77d3a656 /opt/MATLAB/R2025a/bin/glnxa64/factory_settings/compute/project/settings/../../../../../../bin/glnxa64/libmwservices.so+03384918 _ZN15MatlabLicensing11getInstanceEPKN4lmgr6config17LmStartPropertiesE+00002454
[  9] 0x00007f5a7696c741         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00841537
[ 10] 0x00007f5a7697ed3d         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00916797
[ 11] 0x00007f5a7695b1da         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00770522
[ 12] 0x00007f5a7695b69d         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00771741
[ 13] 0x00007f5a8d2dbb17 /opt/MATLAB/R2025a/bin/glnxa64/libmwboost_thread.so.1.81.0+00043799
[ 14] 0x00007f5a8d8969cb                                 /usr/lib/libc.so.6+00616907
[ 15] 0x00007f5a8d91aa0c                                 /usr/lib/libc.so.6+01157644

When install more than 1 products using this PKGBUILD and _product be a product list separated by spaces, --products="${_product// /_}" should be --products=${_product} (no double quote) or mpm cannot recognize it.

@Fitti, a missing dependency could logically explain the irreproducibility. Could you or someone else (using a virtual machine or chroot) test whether installing the commented-out dependencies (lines 25–77) resolves the issue? I unfortunately don’t have the resources to test it myself right now.

Cannot test it myself at the moment, but MathWorks support said this about the issue:

"Thank you for contacting MathWorks regarding your start up issue. 

The error and the crashes seem to be occurring due to incompatible libstdc++.so.6. The current workaround is to follow the instructions in this article:

Why does MATLAB fail to install with a "'std::runtime_error' what(): Unable to launch the MATLABWindow application" error on Linux? https://www.mathworks.com/matlabcentral/answers/540707"

Could be helpful.

@vitaliikuzhdin Yeah, I did apply the patch! Before the patch, it would take a while to launch, and then crash. After the patch, it crashes almost instantaneously.

I might have the time to test with 2024b later today. I will comment here with my results if I do.