Package Details: matlab-gcc13 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 (GCC13 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.102396
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 2 3 4 5 6 7 8 9 10 11 12 .. 29 Next › Last »

bestfriend commented on 2022-09-15 22:57 (UTC)

I omitted the libselinux and gconf dependencies and was able to install R2022a along with several toolboxes. Not sure if/when something will break. Arch Wiki says libselinux is for the help browser and livescripts. Help seems to work, but I don't use livescripts, so I'm not sure about that. Thanks for the package!

Rubo commented on 2022-08-29 19:15 (UTC) (edited on 2022-08-29 19:16 (UTC) by Rubo)

Hi @nisarg13, the PKGBUILD doesn't download the source files. It expects them to be in the same directory where you put the PKGBUILD. You can read the installation instructions here: https://github.com/Rubo3/matlab-aur

nisarg13 commented on 2022-08-29 17:30 (UTC)

Where do find the source files? it seems that the PKGBUILD was supposed to download them during installation, but it doesn't.

Rubo commented on 2022-08-21 20:40 (UTC)

Hi @bbaserdem, thanks for your message. I'm working on a new PKGBUILD with your improvements, hope to release it soon.

silverbluep commented on 2022-08-04 07:11 (UTC)

Couple tidbits;

I'm able to build with just the following makedepends, though my PKGBUILD is slightly different than this one. But mostly similar; as the PKGBUILD is based on mine; and from people whom I used as templates for the previous PKGBUILD.

gendesk
coreutils
findutils
python
ca-certificates
cairo
fontconfig
glib2
krb5
libgcrypt
libselinux
libxcrypt-compat
make
mesa
pam
unzip
util-linux-libs

Do not know if this is the minimal building set; but it is pretty small. Also; in your pkgbuild, the first array of dependencies is enough for me to run matlab without issues. The second array (which I had in the pkgbuild before) seems unneccessary; or at least feature dependent which I did not try. I personally opt to manage dependencies using a metapackage now, since I don't want to reinstall matlab to try new dependencies.

I see that this pkgbuild changes pkgver depending on the installation media. However; it probably won't work for anything 2020> , location of binaries and libraries and their versions are all different. The fixes in the python engine and the package_matlab() version will fail on most older versions. Since it only is guaranteed to work with 2022a, maybe dynamic pkgver is not a good idea?

I initially wrote the python spoofing based on some stuff I found online and through trial and effort. I switched methods; instead of making matlab think it's a lower number of python that is being run I just edited so that python engine thinks it supports 3.10. Have not been able to test if it works this way; but the previous spoofing is disabled (python 3.10 changed the way how sys.version_info works so you can't set it to a tuple, and the engine functions uses different methods which is non-trivial to spoof all around.) My solution is in my pkgbuild here.

Also; my suggestion on people with intel gpu, is that the default driver for mesa is iris; but matlab does not work with it. I used to use i956, but since december 2021; it's out of mesa due to being ancient. zink driver seems to work; so you can launch matlab with MESA_DRIVER_OVERRIDE=zink and hardware acceleration works.

daniel_shub commented on 2022-07-15 15:20 (UTC)

Any chance that MATLAB is lying to you? They have been known to sweep OpenGL issues under the rug

https://www.mathworks.com/matlabcentral/answers/239279-hardware-based-opengl-on-linux#answer_220778

"In the three cases listed previously hardware accelerated versions of Mesa are in fact being used. The problem is that the value of the OpenGL info 'software' field is actually incorrect. This issue has been fixed in R2016a."

Maybe they broke something again.

akristmunds commented on 2022-07-15 10:53 (UTC)

Hi, I messed up my MATLAB installation when I wanted to add additional packages from the GUI. I then decided to uninstall it with sudo pacman -R matlab, and then run the installation again. I followed the installation instructions, this time also installing additional packages. The installation seemed to run correctly, but now when I start matlab from the terminal, I get:MATLAB is selecting SOFTWARE OPENGL rendering., and with $ matlab -nosoftwareopengl, I get nothing. What can I do? Where can I look for error messages or hints of what may be wrong? I'm considering trying to install this again in a VirtualBox.

cxor commented on 2022-07-06 02:08 (UTC)

Also, I keep getting:

Error: No classpath definition jar found.
==> ERROR: A failure occurred in build().

Which apparently means one of the addons can't find the jars in ./matlab/java (./src/matlab/java) that it needs. i'm on a new system and my xorg/i3 isn't quite set up completely. i'm not sure if this is something I can fix by setting the java classpath env var or whether it's actually missing files.

here are the extensions i'm installing:

"MATLAB", "Simulink", "Bioinformatics_Toolbox", "Control_System_Toolbox", "Curve_Fitting_Toolbox", "Deep_Learning_Toolbox", "Econometrics_Toolbox", "Financial_Instruments_Toolbox", "Financial_Toolbox", "Instrument_Control_Toolbox", "MATLAB_Coder", "MATLAB_Compiler", "MATLAB_Report_Generator", "Optimization_Toolbox", "Partial_Differential_Equation_Toolbox", "Reinforcement_Learning_Toolbox", "Robotics_System_Toolbox", "Simulink_3D_Animation", "Simulink_Check", "Simulink_Code_Inspector", "Simulink_Coder", "Simulink Control_Design", "Simulink_Test", "Statistics_and_Machine_Learning_Toolbox", "Symbolic_Math_Toolbox", "Wavelet_Toolbox"

cxor commented on 2022-07-06 01:59 (UTC)

after running the matlab installer, the install.sh script runs makepkg, which can't find these files in the prepare() phase

./src/matlab/installer_input.txt ./src/matlab/install.txt

it seems to pick these up if I just copy them to the required location.

however, running the install.sh script a second time replaces the matlab.tar file with a version of MATLABROOT that has its files deleted. it might help to error out if matlab.tar already exists bc it's been a bit confusing.

another issue that i'm running into is that Ctrl-c on big cp ops leaves my /tmp/ directory full, which causes the script to error again.