gcc 4.3 on SL6.2, User needs access to gcc 4.3

[kross]

Hi all,

We're running Scientific Linux 6.2 on a server, with gcc 4.4. One of our users is running Matlab 2011a, which needs gcc 4.3.x and gfortran 4.3.x. Is there an easy way to have these installed side-by-side with 4.4 without compiling new versions, or possibly a way to run 4.4 in a compatibility mode that supports 4.3?

Thanks very much,

Kevin

[zxq9]

Are you actually getting an error message trying to build MatLab on 4.4?

You should be able to compile a program from 4.3 on 4.4, but not necessarily the other direction. The fun word here is "should".

Have you tried cleaning up your make files and other preprocessing trash? Your build might just be looking for explicit (and now wrong/nonexistant) versions.

[kross]

The version of MatLab is 2011a--for this version Mathworks supports gcc 4.3.x and gfortran 4.3.x. The user is getting an error when running Mex files (MatLab-executables), which in this version apparently depend on these supported versions of gcc and gfortran.

Thanks,

Kevin

[zxq9]

What is the error? If the problem is when running executables the problem is likely a library rebuild problem and not just 4.3 vs 4.4 of gcc and gfortran (as in, linked library binaries aren't consistent with what's in the current package you're trying to run). Have you tried rebuilding MatLab and its dependencies on 4.4?

Without enough information to recreate the situation there's no way anyone can help you with this. But the solution almost definitely is not downgrading gcc (it could be, but in that case the solution is to port MatLab forward, not roadblock your whole system by forcing a system-wide downgrade to 4.3 -- which is way harder to maintain over the long run than patching one program forward).

[kross]

Thanks for taking a look at this. Here's the problem the user is having with Matlab:

"To reproduce the problem:

(1) copy file timestwo.F from /usr/local/MATLAB/R2011a/extern/examples/refbook to a local (writeable folder)
(2) open up Matlab and move to the folder containing timestwo.F
(3) type "mex -v timestwo.F". It should compile successfully
(4) type "timestwo(3.0)". I get a segmentation fault and I expect you will too. One needs to exit Matlab at that point."

We're using R2011a, and we just have access to the binary form so we can't rebuild it. Several users online have reported fixing this problem on Ubuntu ("https://help.ubuntu.com/community/MATLAB", the section on Mex functions )by installing the older versions of gcc and gfortran. I was wondering if there's a way to keep the newer versions but also install 4.3 through either yum or rpm. I think it might be simpler to try to upgrade to a newer version of Matlab, though, and we're looking into getting that.

Thanks,

Kevin

[zxq9]

Hrm... looking into this further (and playing with Octave, incidentally, just for fun, which turned out to be pretty slick, but different)...

2011a doesn't seem to understand a few of the things it needs to work well with gcc4.4, but only in some circumstances. This is pretty weird. I'm not sure if its putting code out with bad pointers or what, but "sometimes-segfaults" make this appear to be the case. Sometimes the files you compile with 4.4 will work, but it depends on the state of the stack when you run the executable -- actually, it reminds me of the hit-or-miss nature of old-school NOP-slide attacks from my childhood. This sort of thing is no-fun/not-worth debugging, imo.

2012a works with gcc 4.4, but you might not have that available.

So...

I actually found an ancient snapshot of 4.3 archived:
http://ftp.tsukuba.wide.ad.jp/software/gcc/snapshots/4.3-20110626/
and the SL 5.8 sources for 4.3 is here:
ftp://ftp.jaist.ac.jp/pub/Linux/scientific/58/SRPMS/vendor/gcc43-4.3.2-7.el5.src.rpm

The SL5 source package looks the most promising. Feeding it to mock with no modifications dies on mismatched gmp library versions (duh...) but I think this could be worked around pretty easily -- gcc doesn't have that many dependencies, anyway.

If this problem is really widespread -- like MatLab 2011a on SL 6 is crushing hopes and dreams all over the Kingdom of Nerd then I might be able to build a self-contained gcc43-4.3-1.el6.x86_64.rpm that parallel installs and would have to be invoked using "gcc43" and "gfortran43" to prevent mucking up the rest of the system. If it becomes much of a time sink, though, I'd have to abandon it because I'm really busy in other areas atm.

[kross]

Thanks. For now we're trying to get the newer version.

I read that someone else with this problem had success with the g95 compiler.

What do you think about just getting the source for one of the gcc 4.3.x versions and compiling it locally, then I could point something like you suggest, gcc43, gfortran43 to that? Might try that if the newer version idea falls through.

Thanks again,

Kevin

[zxq9]

I just read over the spec file for the srpm I linked earlier. I didn't have time to look too deeply, but it looks like it should be pretty easy to rebuild this statically in mock for an el5 environment, and install it as gcc43 as a single static binary blob. I don't like static compiles since I'm not a Windows developer, but its probably the best way to get what you want here without spending a lot of money on new MatLab versions.

The most important parts are: making sure the static compile works well (shouldn't be too hard, though there is a small book's worth of $OPT_FLAGS and things to check through to make sure you're not telling make or gcc crazy things), and adjusting the %install section to conform to what the el6 packages do and relabeling them to read "gcc43" instead of just "gcc" (or else you'll never call the real v4.4 one again unless you give a full path -- ouch).

Anyway, not too hard, I think -- because mock will take care of all the messy bits for us. I just don't have time to mess with it tonight.

[kross]

I got the source for gcc 4.3.6 and compiled that to /usr/local/gcc43. Then I changed the $PATH variable to add /usr/local/gcc43/bin before /usr/bin. Matlab seems to have picked up the older versions of gcc/gfortran with no other modification necessary, as the example I got from the user now works. I'm going to have the users test to see if other Mex files are now working.

Kevin

[zxq9]

Awesome! If you don't have many systems to cover that might be an easy fix. If you do then you could write a really easy RPM and push it out to everyone. I would recommend not intercepting the $PATH, though, and instead doing something like:

CODE

ln -s /usr/local/gcc43/bin/gcc /usr/bin/gcc43

and whatever else you need easy access to. That way you don't flip the whole system to gcc43 just to compile Mex files (which would screw up compiling real Fortran or C, in addition to everything else that isn't MatLab that depends on gcc 4.4). When compiling the Mex files you would need to explicitely call gcc43, and if that's too hard for people to remember then you could write a shell wrapper to make it easy for them named something like "makemex" or whatever so they can't get turned around easily.

I don't recommend messing with $PATH is cases like this, though, because its a big hammer to fix a really niche problem a symlink is more appropriate for (and I think the alternatives system could be useful here also, but I'm just not very familiar with it myself).

[kross]

I think for now it's just this one system--if we need to roll it out to others I'll look into creating an RPM (haven't done that before so it should be interesting).

The symbolic link idea makes sense, much better than changing the path. I'll implement that and see if the users can change the ggc they're calling to something like gcc43.

zxq9, thanks for your help.

Kevin