Installing matlab on centos 7

When I run the installer in R2015b with the command "./install", it prints

        Preparing installation files ...
        Installing ...

Then a small matlab window appears. Then it prints

        Finished

and the matlab window disappears and the command prompt reappears. Nothing appears to be installed. Now what?

[Peter Knoppers]

I managed to "transplant" R2015A from an ubuntu system (the previous location of the matlab program that we want to run). Copied the entire tree to the Centos 7 machine and ran the matlab binary. It complained that the license file was invalid for that machine (correct) and indicated how to fix that. That fix worked! So I have a work-around, but it would be better if the new machine ran R2015B and the installer should produce usable diagnostics.

[Paul Hankewicz]

How did you manage to do that? Or at least the license part?

Answer 1

[Walter Roberson]

sudo ./install

[Peter Knoppers]

I tried that as well. Same result. Even made an strace log. Logged 52468 system calls. I believe the installation fails at some point and then removes all installed files. If anyone wants to inspect that strace output; I'll gladly make it available.

[Walter Roberson]

Data point: For R2016b

I used the "Download only" feature first, as I end up installing on multiple Linux versions.

I started up my CentOS 7 virtual machine, cd'd to the installer glnxa64 directory, and did

sudo bin/glnxa64/install_unix

and followed the install sequence. The install and activation worked with no problem.

I then started up MATLAB R2016b without difficulty.

The problem comes after that:

>> plot(1:10)
Error using gca
While setting property 'Parent' of class 'Axes':
Can't load '/usr/local/MATLAB/R2016b/bin/glnxa64/libmwosgserver.so':
/usr/local/MATLAB/R2016b/bin/glnxa64/libosgViewer.so.80: undefined symbol: glXDestroyGLXPbufferSGIX

Error in newplot (line 73)
    ax = gca(fig);

This is a known issue, a conflict between the older interface that MATLAB is linked against and what CentOS has installed.

It turns out to be a longer process to fix, requiring the installation of a number of packages, some of which do not appear to be readily available as distributions. Older compilers had to be installed too if I recall correctly, as some of the packages refused to use the newer compilers.

I gave up on the process after several hours when I was trying it for Debian 7.

I do not know if installing an older MATLAB release would work.

Answer 2

[Steffen Zschaler]

I am also having this problem. I am on a CentOS 7 virtual machine, trying to install Matlab R2017b. I'm logged in via ssh -X and run the installation using sudo ./install -v from a downloaded and extracted ZIP file.

Does anyone have a solution to this problem?

Many thanks,

Steffen

Answer 3

[Steffen Zschaler]

I seem to have managed to get around this. I was missing libXtst.so.6 on my machine. Once I installed this using yum install libXtst, the installation seemed to go through (note Matlab installer is still working as I write this, so other issues might still occur).

The way I found out is by changing the install_unix script in bin/glnxa64. Somewhere towards the end there was an eval which runs the java installer and pipes all output to /dev/null. Removing that pipe allowed me to see what the problem was.

Steffen

Answer 4

[Decio Fonini]

The installer must run as root AND it must be able to open a GUI, or else the installer fails silently.

So, before running the installer as root make sure root can open, say, xterm or kcalc.

[Steffen Zschaler]

Thanks, Decio. Two points though:

1. The installer shouldn't fail silently in the first place. In fact, the current install scripts actively suppress output from the Java part of the installer which would have helped me understand more quickly what the problem was. I would consider this a bug in the current install scripts.
2. I had already got X set up on the bare-bone CentOS VM I was given. In fact, before the installer failed, it briefly showed me the splash screen. I never tried running xterm or similar, but I guess the fact that it was able to show the splash screen shows that at least some parts of X were working OK. So actually the problem was much more specific than just saying "needs to be able to open a GUI".

Steffen