Package Details: matlab-gcc11 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 (GCC11 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.100348
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-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

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 29 Next › Last »

silverbluep commented on 2021-01-31 02:19 (UTC) (edited on 2021-01-31 02:22 (UTC) by silverbluep)

I'm on a zen2 microarchitecture (AMD Ryzen 7 3700x) and it works fine. It probably is something else related specifically to your desktop. If you are not using it already; I suggest installing amd-microcode and making sure your bootloader loads the related ramdisk before loading initrd.

Either way; you can build the package on your server; copy the tar.zst file to your desktop and install using pacman -U matlab.blabla.tar.zst. For activation; after installation you can run sudo activate_matlab.sh; but you shouldn't need to if you used the licence that is appropriate for your PC (using the MAC address of any of your ethernet interfaces; as far as I recall.)

Please post this in mathworks forums; as anyone else on other linux distros having the same problem can benefit from your experience; or help diagnose what exactly is going wrong.

Hork commented on 2021-01-31 00:02 (UTC)

Strangely enough, I copied exact same files to my arch server and it runs. I guess that architecture issue still persists on this version and I'm running my desktop on AMD zen2.

auricom commented on 2021-01-30 13:43 (UTC) (edited on 2021-01-30 13:44 (UTC) by auricom)

I've installed the latest update and it seemed to go without any hitches apart from having to re-activate Matlab afterwards. Many thanks bbaserdem!

Everything I've tested works fine apart from Matlab's built-in updater which notifies me about an update but always fails during the installation with the message "Something unexpected occured". However I don't think the updater has ever worked for me when installing Matlab via the AUR package and it's certainly not a problem specific to this latest PKGBUILD.

I'm guessing it's some kind of permissions error but not really sure. Has anybody else managed to use it successfully?

silverbluep commented on 2021-01-30 08:41 (UTC)

I would check mathworks forums for a fix; as if the provided installer is not working on your system it's an issue on the installer end. I can't replicate your issue so I don't know how to help you.

If you find the solution please post it here.

Hork commented on 2021-01-29 20:49 (UTC)

Seems to be a matlab installer issue. Cannot install even with their default installer. Generate a "archive is not a ZIP archive" error but last one has this issue is way back to 2016a. No idea what's going wrong there.

Hork commented on 2021-01-28 19:06 (UTC)

Not really, I created the tar bar exactly as the md instructed. However, the downloaded matlab folder does not have that file in the first place.

silverbluep commented on 2021-01-28 16:26 (UTC)

I assume this is a problem with the way you created the tar file; did you follow the instructions as exactly stated in the README provided by the repo? I would delete the one you have and recreate the needed files.

Hork commented on 2021-01-28 10:47 (UTC) (edited on 2021-01-28 10:49 (UTC) by Hork)

I straced that matlab/bin/glnxa64/install_unix, stat("/tmp/makepkg/matlab/src/matlab/sys/java/jre/glnxa64/jre/lib/security/jssecacerts", 0x7fffe1f6baf0) = -1 ENOENT (No such file or directory) is what I suspect wrong. Do you have this file in your downloaded matlab folder?

silverbluep commented on 2021-01-27 19:44 (UTC) (edited on 2021-01-27 19:47 (UTC) by silverbluep)

What is that installer? I can't help if you are not being specific. The installer for MATLAB does not print to stdout; and that's on mathworks nothing I can do. There should be some installer log somewhere; but I don't know where the installer puts it. Your problem is not due to python; because anything to do with python is printed on stdout when you run makepkg.

You don't need to do any chrooting; install dependencies, bring together the neccessary files and mimic the PKGBUILD steps (on your home directory; NOT on your main system.) Be sure to read the README.md in the repo, and make sure you are not using ANY aur helper.