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.

Obviously AUR dependencies needs to be resolved by you; that's how AUR works. I suggest getting acquainted, but there should be no issues installing gcc8 using an aur helper.

Try running matlab -nodesktop from a terminal; and if you get to the console that means it has something to do with your graphical desktop. I don't know how to resolve your issue, never encountered it.

You can also try de-integration by replacing the symlinks in /opt/tmw/matlab-2020b with the static libraries in /opt/tmw/matlab-2020b/backup to see if it's an integration issue. That or install matlab locally in your home folder using only the mathworks installer and see if it works.

Followed the README.md and makepkg was failing to resolve the gcc8 dependencies, I've tried installing gcc8 manually (only supported through the aur - this also needed to be built using PKGBUILD as the aur helper is not supported) then had to comment out these dependencies in the PKGBUILD.

The build seemed successful however once I run the matlab file I get an empty grey text box with the window title "Error Starting Desktop", not even the only button (I'm assuming says close) has text.

Let me know if you need further details

@bbaserdem; Thanks for your reply.

I am not very sure what you mean by "in the presence of either or both llvm-libs and gcc-libs would solve the problem" since I don't think it's quite possible to remove package "llvm-libs" or even "gcc-libs". Perhaps I misunderstood your words.

Do you mean try to install a lower version of llvm-libs or gcc-libs?

Update 2021.2.22

I found that running matlab through "LD_LIBRARY_PATH=/usr/lib matlab" can suppress (fix?) the error and OpenGL is correctly loaded. But I do not know whether this will affect matlab loading gcc8 libs.

If that was an issue; I would have the same issue, but I don't. I assume the presence of either or both llvm-libs and gcc-libs would solve the problem?

@billypilgrim, could you check it out? (On the PC that the built installable pkgbuild won't work; first install llvm-libs, try to open, then remove llvm-libs and install gcc-libs, try to open, then install llvm-libs again and try to open.) Then could you report? If you give it green light; I'll add the necessary packages as dependencies.

@billypilgrim, @bbaserdem;

Problem description

I also encountered billypilgrim's problem. It seems that mesa libs (called by OpenGL lib) use llvm-libs (provides libLLVM-11.so) and llvm-libs uses gcc-libs (provides libstdc++.so.6). The problem is that line 262 in PKGBUILD tells matlab (and possibly libs called by matlab) to find libs from gcc8-libs path (for me /lib/gcc/x86_64-pc-linux-gnu/8.4.0) first, which is necessary for matlab but possibly not (even harmful) for some other libs. Or, in other words, the current version of llvm-libs requires a higher version of gcc-libs than gcc8-libs to properly function.

I think the problem could be fixed if the updated lib path can be excluded for OpenGL, but I do not know how to achieve this.

System Inform

• Linux Satellite 5.10.15-1-MANJARO #1 SMP PREEMPT Wed Feb 10 10:42:47 UTC 2021 x86_64 GNU/Linux
• Package version:
  • gcc-libs:10.2.0-6
  • llvm-libs:11.0.1-2
  • mesa:20.3.4-1
  • matlab:9.9.0.1467703-4(latest)

@bbaserdem; Thanks for the gcc package update!

@billypilgrim check out the archwiki page for intel related issues as well; they might relate. I don't have issues with amdgpu and this pkgbuild. Check out your card; i have AMD Radeon RX 5700 XT

Please report back if you manage to fix it; and it's fixable (a missing dependency or launch options) so I can add a fix/dependency to the pkgbuild.

Is anyone else getting issues with amdgpu?

This is what I get in my terminal when I start matlab: libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/gcc/x86_64-pc-linux-gnu/8.4.0/libstdc++.so.6: version GLIBCXX_3.4.26' not found (required by /usr/lib/libLLVM-11.so) (search paths /usr/lib/dri) libGL error: failed to load driver: radeonsi libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/gcc/x86_64-pc-linux-gnu/8.4.0/libstdc++.so.6: versionGLIBCXX_3.4.26' not found (required by /usr/lib/libLLVM-11.so) (search paths /usr/lib/dri) libGL error: failed to load driver: radeonsi libGL error: MESA-LOADER: failed to open swrast: /usr/lib/gcc/x86_64-pc-linux-gnu/8.4.0/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib/libLLVM-11.so) (search paths /usr/lib/dri) libGL error: failed to load driver: swrast

And here's the error message I get within the matlab GUI once it's loaded: com.jogamp.opengl.GLException: X11GLXDrawableFactory - Could not initialize shared resources for X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x0, owner false, ResourceToolkitLock[obj 0x643bdb87, isOwner false, <29e4dacf, 2c84828b>[count 0, qsz 0, owner <NULL>]]] at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:326) at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:297) at java.lang.Thread.run(Thread.java:748) Caused by: com.jogamp.opengl.GLException: AWT-EventQueue-0-SharedResourceRunner: Unable to create temp OpenGL context(1) at jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:368) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:759) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:642) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:580) at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:297) ... 2 more

I can still open figure windows etc. but OpenGL is disabled.

That seems to be /tmp no enough space issue, not sure if this makepkg error was also caused by that.

Read the readme.md, and use unzip -X -K to resolve libexpat issue. Rename your installer dir to something else, download to a folder called matlab and tar it there.