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 They actually changed it to /opt/MATLAB/R2025a/..., which is where I placed the files. I tried your symlink method, as well as dumping them in there directly. I tried multiple different installation methods, aside from this AUR package, and none of them worked. All that happens is that MathWorksProductActivation works, which would otherwise also crash, and the [ 0] entry in the stack trace changes. Sadly, I will no longer be able to test for a bit, as the license itself is apparently "used up" now, despite me having precisely none working installs. I hope they fix my license.

I would guess you would replace

MATLABPATH=/opt/tmw/matlab-r2024b/bin/glnxa64/

with

MATLABPATH=/opt/tmw/matlab-r2025a/bin/glnxa64/

Can you see files in "${MATLABPATH}"/gnutls and symbolic links to those files in "${MATLABPATH}"?

@aoneko I'm trying to apply the fix to R2025a as well, but haven't had any success so far. It still crashes with the same error. How exactly did you modify the commands from Daniel's fix to work for you?

I just noticed that the first line in my stack trace is different, though the 15 following it are identical: [ 0] 0x00007fd45c441c68 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+02366568 lc_new_job+00000216

@daniel_shub Thank you for this important information. After pasting gnutls 3.8.9 for Matlab R2025a, it can be both activation and operation. Thank you and Vitaliikuzhdin for all those hard work!

@vitaliikuzhdin I would hold off until gnutls 3.8.10 hits the Fedora and/or Debian repos to see if it breaks other things and how people fix it.

Right now I a using

# MATLABPATH=/opt/tmw/matlab-r2024b/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}
# mkdir "${MATLABPATH}"/gnutls
# cp -a "${GNUTLSPATH}"/usr/lib/* "${MATLABPATH}"/gnutls/
# cd "${MATLABPATH}"
# ln -s gnutls/* ./

So we could create a gnutls389 package and create the needed links in matlab-r2024b/bin/glnxa64/ or just add the old package as binary source and put them in matlab-r2024b/bin/glnxa64/.

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