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.

@daniel_shub, you are right, sorry. I posted the reply as soon as possible to help people get started, but I should have double-checked first. What solution would you propose? Perhaps I could write a non-conflicting package with an older version of gnutls and replace the symlinks in /usr/bin with shell scripts that preload it.

@vitaliikuzhdin I am pretty sure the problems @aoneko and @Reexys are not related to the execstack and are rather related to an issue with the newest gnutls, but I am still on 2024b so cannot be certain. I posted a work around at https://bbs.archlinux.org/viewtopic.php?pid=2251599#p2251599

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.

@aoneko

I'm currently also experiencing the same issue. Hopefully it's just something to do with their servers and maybe some licence validation. Not entirely sure what the issue is however.

I tried this PKGBUILD and installed dependencies manually. However, every time I ran Matlab I got the following error message:

Configuration:
  Crash Decoding           : Disabled - No sandbox or build area path
  Crash Mode               : continue (default)
  Default Encoding         : UTF-8
  Desktop Environment      : GNOME
  GNU C Library            : 2.41 stable
  MATLAB Architecture      : glnxa64
  MATLAB Root              : /opt/MATLAB/R2025a
  MATLAB Version           : 25.1.0.2943329 (R2025a)
  Operating System         : "Arch Linux"
  Process ID               : 11578
  Processor ID             : x86 Family 6 Model 186 Stepping 2, GenuineIntel

Fault Count: 1


Abnormal termination:
Segmentation violation

Current Thread: 'MCR 0 interpret' id 134325228005056

Register State (from fault):
  RAX = 0000000000000000  RBX = 00007a2b077fbd88
  RCX = 00007a2bf5e3bcc0  RDX = 00007a2bf5e130c0
  RSP = 00007a2b077fbcf0  RBP = 00007a2b842c4900
  RSI = 0000000000001000  RDI = 0000000000000000

   R8 = 00007a2bf5e39f20   R9 = 00007a2bf5e39fa0
  R10 = 00007a2bf5e3a138  R11 = 00007a2bf5e3a140
  R12 = 0000000000000000  R13 = 00007a2b077fbd10
  R14 = 00007a2b077fbd20  R15 = 0000000000000000

  RIP = 00007a2b842fe008  EFL = 0000000000010246

   CS = 0033   FS = 0000   GS = 0000

Stack Trace (from fault):
[  0] 0x00007a2b842fe008 /opt/MATLAB/R2025a/bin/glnxa64/connector_plugins/notifications/subscriber_impl/../../../../../bin/glnxa64/libmwinstall_activationwsclientimpl.so+00499720 lc_new_job+00000216
[  1] 0x00007a2b0435ccaf /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01428655
[  2] 0x00007a2b0435d735 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01431349
[  3] 0x00007a2b043c7274 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01864308
[  4] 0x00007a2b0435fb56 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01440598
[  5] 0x00007a2b0435e57d /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01435005
[  6] 0x00007a2b0438ef40 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01634112
[  7] 0x00007a2b0c033437 /opt/MATLAB/R2025a/bin/glnxa64/authz/licensing/product/matlab_impl/mwlicensingproductmatlab.so+00160823
[  8] 0x00007a2c42b3a656 /opt/MATLAB/R2025a/bin/glnxa64/factory_settings/compute/shared_cmlink/settings/../../../../../../bin/glnxa64/libmwservices.so+03384918 _ZN15MatlabLicensing11getInstanceEPKN4lmgr6config17LmStartPropertiesE+00002454
[  9] 0x00007a2c40677741         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00841537
[ 10] 0x00007a2c40689d3d         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00916797
[ 11] 0x00007a2c406661da         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00770522
[ 12] 0x00007a2c4066669d         /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00771741
[ 13] 0x00007a2c4c0a6b17 /opt/MATLAB/R2025a/bin/glnxa64/libmwboost_thread.so.1.81.0+00043799
[ 14] 0x00007a2c4bca57eb                                 /usr/lib/libc.so.6+00612331
[ 15] 0x00007a2c4bd2918c                                 /usr/lib/libc.so.6+01151372

The lines

# Needed for programs like python-matlabengine which expect MATLAB to be in /usr/local
install -dm755 "$pkgdir/usr/local"
ln -s /$_matlabdir "$pkgdir/usr/local/MATLAB"

violate the Arch packaging guidelines (https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette) which says "Packages should never be installed to /usr/local/" and is in fact not needed (at least for python-matlabengine). That page https://github.com/mathworks/matlab-engine-for-python) says "When MATLAB is not installed in the default location, the bin/architecture directory within the MATLAB root directory must be added to the environment variable LD_LIBRARY_PATH"

Seems that resetting the owner of the folder /opt/MATLAB by chown can solve the problem of "Something unexpected occurred" when installing APPs. This is definitely not the best solution, but it works. I'm not sure about that.

@amad3v I moved it because sometimes MATLAB expects it to be installed there, if not you'd have to edit LD_LIBRARY_PATH, as is the case with python-matlabengine. But since it seems impossible to retrieve the license file to install it offline from R2023b+, I'll likely move it to /opt one day.