Package Details: matlab-gcc-fortran 1:R2025a+25.1.0.2973910-1

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 (GFortran runtime dependency)
Upstream URL: https://www.mathworks.com/products/matlab.html
Keywords: computation matlab numerical visualization
Licenses: custom:MATLAB EULA
Provides: matlab-gcc-fortran, matlab-gcc-fortran-release, matlab-gcc-fortran-version
Submitter: ido
Maintainer: vitaliikuzhdin
Last Packager: vitaliikuzhdin
Votes: 41
Popularity: 0.26
First Submitted: 2015-08-15 09:33 (UTC)
Last Updated: 2025-07-30 20:23 (UTC)

Dependencies (5)

Required by (1)

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 2 3 4 5 6 7 8 .. 28 Next › Last »

Rubo commented on 2023-09-21 11:35 (UTC)

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

amad3v commented on 2023-09-21 11:24 (UTC)

@Rubo

I think it's better to move the installtion to /opt

Rubo commented on 2023-09-19 12:23 (UTC)

I'd like to support R2023b, but it seems it's not possible to retrieve the license file from this version onwards. If anyone knows how to do it, please message me.

imcb commented on 2023-04-26 20:59 (UTC)

Patch to add some extra instructions and gitignore: https://github.com/joelsgp-pkgbuild/matlab/commit/a38749702ebe7bc90e86271d537d1bae18be94d6.patch

tornado99 commented on 2023-01-23 15:55 (UTC) (edited on 2023-01-24 14:42 (UTC) by tornado99)

For the R2022b Add-Ons installer to launch you to exclude libtiff.* Also without excluding you get a 'Failed to load bundle #392: /opt/MATLAB/R2022b/bin/glnxa64/libmwrtifc.so' error when trying to use certain addons. Perhaps add this fix to the pkgbuild?

Edit: this may be have been fixed recently in Arch, as after a system update I had to move back libtiff.* to glnxa64 to get MATLAB to run normally.

Rubo commented on 2023-01-17 17:56 (UTC)

@alhirzel thanks, I added a simplified version.

alhirzel commented on 2023-01-17 17:09 (UTC)

I would like to contribute this snippet that warns the user if the installer (silently) fails. This is detected by the $srcdir/build directory being empty after running the installer:

diff --git a/PKGBUILD b/PKGBUILD
index 50cad05..98adb44 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -49,6 +49,15 @@ build() {
     # -inputFile makes the installation non-interactive.
     "$srcdir/matlab/install" -inputFile "$srcdir/matlab/installer_input.txt"

+    # if it fails, output dir will be empty and there will be a log entry
+    if [ `ls "$srcdir/build" | wc -l` -eq '0' ]; then
+        error "MATLAB installer failed; check install.log:\n"
+        tail "$srcdir/../install.log"
+        echo ""
+        error "^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"
+        exit 1
+    fi
+
     echo "  -> Generating desktop files..."
     gendesk -f -n \
         --pkgname 'matlab' \

Rubo commented on 2023-01-07 15:35 (UTC)

I have updated the PKGBUILD to the latest R2022 point release. In order to comply with the Arch package guidelines, the installation directory is no more /usr/local, but /opt. This required a change in python-matlabengine, because by default the installation script looks for the MATLAB root into /usr/local, so now the MATLAB root is exported via $LD_LIBRARY_PATH (only on this occasion, it won't touch your $LD_LIBRARY_PATH).

/opt/MATLAB/R2022b has temporarily gained 777 permissions in order to install additional toolboxes. Unfortunately I am not able to do so, because during the installation I get "Something unexpected occurred". If you are able to install them, please contact me. I would like to resolve this issue once and for all.

If you have any issue, please let me know.