Package Details: matlab-gcc 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 (GCC runtime dependency)
Upstream URL: https://www.mathworks.com/products/matlab.html
Keywords: computation matlab numerical visualization
Licenses: custom:MATLAB EULA
Provides: matlab-gcc, matlab-gcc-release, matlab-gcc-version
Submitter: ido
Maintainer: None
Last Packager: vitaliikuzhdin
Votes: 41
Popularity: 0.30
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 .. 12 13 14 15 16 17 18 19 20 21 22 .. 28 Next › Last »

japm48 commented on 2020-03-27 00:10 (UTC) (edited on 2020-03-27 00:56 (UTC) by japm48)

While trying to install r2020a I had this error after executing ./install:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Unable to launch the MATLABWindow application

I solved this by installing libselinux (in AUR).

For the record: I found the missing dependency by executing ./bin/glnxa64/MATLABWindow.

Besides, it works without gtk2 (perhaps it now depends on gtk3).

medicineman25 commented on 2020-03-04 23:23 (UTC)

Just got this when trying to install

==> Making package: matlab 9.7.0.1296695-1 (Thu Mar 5 10:15:31 2020) ==> Retrieving sources... ==> ERROR: matlab.tar was not found in the build directory and is not a URL. Error downloading sources: matlab

Going to go the manual route for now

greyltc commented on 2020-01-28 19:01 (UTC)

@kyak oh cool, thanks. The deps here definitely do need some work!

kyak commented on 2020-01-28 18:31 (UTC)

@greyltc thanks for the effort!

I'd like to point you to the now official Dockerfile from MathWorks themselves: https://github.com/mathworks-ref-arch/matlab-dockerfile/blob/master/Dockerfile and https://hub.docker.com/r/mathworks/matlab-deps/dockerfile.

It can be useful for us to get all the dependencies correctly.

greyltc commented on 2020-01-28 17:34 (UTC) (edited on 2020-01-29 10:03 (UTC) by greyltc)

I've just fixed a number of bugs in the PKGBUILD, so as of today with r2019b update 3, I can verify that it's up to date and working. Apologies I don't get around to updating this too often. I don't reinstall MATLAB so frequently to keep up with all the releases. If you'd like to help maintain it, let me know and I can add you as a co-maintainer. The install instructions in the wiki look mostly okay (though I haven't followed them to check that), but hopefully you should just be able to get by with reading my notes in the PKGBUILD its self.

ragouel commented on 2019-11-20 11:49 (UTC)

Matlab won't install, what am I doing wrong ?

Error: This folder name is invalid. Folder names can contain alphanumeric characters and '-', '_', '.', or '/' only. The destination folder cannot be named "private".

Det commented on 2019-10-21 12:08 (UTC)

Update, please?

6etacat commented on 2019-09-13 06:08 (UTC)

The wiki is updated to solve the following error:

Using a File Installation Key requires you run the installer from a MATLAB DVD or from a directory which contains files previously downloaded via the installer.

https://wiki.archlinux.org/index.php/MATLAB#Installing_from_the_AUR_package

7cff commented on 2019-03-11 18:42 (UTC) (edited on 2019-03-11 18:42 (UTC) by 7cff)

When the installer comes up on this error:

Using a File Installation Key requires you run the installer from a MATLAB DVD or from a directory which contains files previously downloaded via the installer.

makepkg doesn't stop running, but rather continues and will even install an empty binary that doesn't function. I'm well aware of the proper way to acquire the Matlab files to build the package, but is there a way to get the PKGBUILD script to halt on this error?

greyltc commented on 2018-12-19 20:47 (UTC)

@jadesoturi The .zip you download from tmw only contains the files needed to run the installer, not all the files required for installation. You need the complete iso. Alternatively, you can run the installer manually, it will download the proper contents of the archives/ folder to a folder in /tmp/. You can then use those files along with the contents of the .zip you previously downloaded to generate the matlab.tar that this package needs to build.