Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I installed Mathematica 9 on an old Red Hat Enterprise Linux AS release 4 system. After the installation, I tried to start Mathematica, but following message came out:

/home/wcbao/M/Wolfram/Mathematica/9.0/SystemFiles/FrontEnd/Binaries/Linux-x86-64/Mathematica: /lib64/tls/libc.so.6: version `GLIBC_2.4' not found (required by /home/wcbao/M/Wolfram/Mathematica/9.0/SystemFiles/Libraries/Linux-x86-64/libML64i3.so)

/home/wcbao/M/Wolfram/Mathematica/9.0/SystemFiles/FrontEnd/Binaries/Linux-x86-64/Mathematica: /lib64/tls/libc.so.6: version `GLIBC_2.4' not found (required by /home/wcbao/M/Wolfram/Mathematica/9.0/SystemFiles/Libraries/Linux-x86-64/libQtCore.so.4)

I don't want to update the system glibc, because it's risky and the administrator don't allow me to do that.

Someone suggested that it is possible to just install new version of glibc somewhere else, and run the program as

LD_LIBRARY_PATH=/lib/new your_application

and this will not affect the system.

So I am asking here if this method really works. And if it works, I want to know how to do it step by step (I lack experience in Linux right now, and want to use Mathematica on Linux as soon as possible).

Edit:

I noticed that there is a software called "Ermine". It seems that it can deploy a software as standalone package which doesn't rely on the external environment. Unfortunately, it is a shareware. So I think since "Ermine" can do it, there must be a way to use new software on old system.

share|improve this question
2  
It would work. It's likely to be quite a lot of work to set up (you'll need to install all the libraries that Mathematica depends on). My recomemndation would be to install rpm packages from a newer release in a subdirectory of your home. I'll let someone who's more familiar with RH write an answer explaining how to do that. –  Gilles Jan 29 '13 at 22:38
    
@Gilles Hi,Gilles,thank you very much!!! I am looking forward to it. –  user15964 Jan 29 '13 at 23:53
    
It is risky to install glibc elsewhere. –  BenjiWiebe Jan 30 '13 at 3:42
    
@BenjiWiebe - what kind of risks are you exactly referring to? –  FooF Feb 2 '13 at 6:54
1  
Cross-posted from superuser: superuser.com/questions/543249/… Repeating my comment from there: "RHEL4 is eight years old and has reached the end of its normal support life cycle. Isn't there another machine you could install it on? eg. Your desktop machine." –  Burhan Ali Feb 5 '13 at 8:00

3 Answers 3

up vote 7 down vote accepted
+50

You can definitely compile a new version of GLIBC and have it stored in a separate directory. The first thing you'll have to do is download the version of glibc that you want from http://ftp.gnu.org/gnu/glibc/.

Run the configure script and set the --prefix= to something like /home/you/mylibs.

After you've managed to install it into that directory, you'll have to set your LD_LIBRARY_PATH to the location of the new glibc.

You'll need to figure out any dependencies you may need to compile. You can create a shell script that sets the LD_* variables and the runs your program (which you'd have to do anyway), and run it repeatedly - download/recompiling missing lobs along the way.

You could also use ldd to determine what shared libraries the program needs, then use ldd on each of the libraries to find out if they require glibc.

This can be a very time consuming process and is not for the impatient or faint of heart - traversing/recompiling your way through the possible dependencies required to make your application work may occasionally make you want to pull out your hair.

Update 1:

I downloaded glibc-2.4 and tried to compile it on CentOS 6. To get configure working properly I had to change the ac and ld version checks by changing:

2.1[3-9]*)

to:

2.*)

at lines 4045 and 4106 in the configure file itself. I set my *FLAGS environment variables like so:

LDFLAGS="-Wl,--sort-common -Wl,-zcombreloc -Wl,-znow" 
CFLAGS="-pipe -fomit-frame-pointer -g1 -O3 -frename-registers -fweb -ftracer -fmodulo-sched -fvariable-expansion-in-unroller -fgcse-sm"
CXXFLAGS="${CFLAGS}" 
CFLAGS="${CFLAGS} -freorder-blocks-and-partition" 
export LDFLAGS CFLAGS CXXFLAGS

and then executed ./configure --prefix=/home/tim/masochist. It configured properly... and it began building properly too... but then I started running into errors - mostly the compiler complaining about things being redefined.

At that point I gave up... Because it was becoming too time consuming. ;)

share|improve this answer
    
+1 for the information, though the last line is important. The OP needs to decide if the amount of effort involved is worth it. –  Burhan Ali Feb 5 '13 at 21:40
    
Thank you All! OK, I resign. I think I'd be better to stick with Mathematica 8 as a compromise. It works on Red Hat 4. –  user15964 Feb 7 '13 at 3:09
    
@livingstaccato Hi, But How do comment vonbrand's words:" Installing a new version in some strange place is riskier... The library at the strange place could be picked up by random stuff,....". Is it really riskier? Had you ever tried the way which is described in your answer? –  user15964 Feb 7 '13 at 3:16
    
@user15964 It's not risky unless you're not paying attention to what you're doing as root or you do something weird like change your LD_PRELOAD in your session init script and lock yourself out. –  livingstaccato Feb 7 '13 at 8:52
    
@user15964 Also - yes - I have rebuilt glibc way, way, back in the day. –  livingstaccato Feb 7 '13 at 9:16

In this particular instance I would say don't bother, unless you have assistance (and permission) from the administrators of this shared system.

Mathematica runs on Windows, Mac and Linux so just install it on your desktop machine where you don't have to worry about affecting others. It's also more likely that the OS will be more recent than RHEL4 and you will therefore not have to do any contortions to install it.

share|improve this answer

Updating glibc to a version supported by your distribution is low-risk. It is written to handle compatibility with versions that date far back, and (baring bugs) a new version should just be a drop in replacement. Installing a new version in some strange place is riskier, IMHO.

share|improve this answer
3  
but the problem is I am not the administrator, I don't have the authority. Even if I got the permission, I am afraid to do changes to the system, because that is not my computer,it is actually a cluster, many people works on it. By the way, why a new version in other place is risky? I only need to link the software I needed to new lib, not the whole system. –  user15964 Jan 29 '13 at 14:31
1  
And you feel free to install some random package? The system administration policies are overdue to a serious revision. The library at the strange place could be picked up by random stuff, and ironing out the running of your application only (and possible processes started by it, that don't involve standard programs) could turn out quite a challenge... –  vonbrand Jan 29 '13 at 14:36
    
@vonbrand - Nonsense, unless we are talking about some high security machine (and not for example some shared developer or testing machine/cluster) in which case you do need to have healthy paranoia about foreign unaudited software. In terms of random breakages, it is quite a different matter to update libc (affecting all the system, possibly causing system breakages) than just installing an isolated application program from trusted sources (I disagree with the notion that Mathematica is random package). Resource exhaustion of course is a valid concern that competent sysadmin should address. –  FooF Feb 6 '13 at 4:08
    
@FooF, I've seen too many cases of "Administration knows best, let users do as they want with no support" to have illusions in this area. –  vonbrand Feb 6 '13 at 5:28
    
@vonbrand - I tend to agree with your last comment. But I strongly disagree that updating libc or installing well known software (not "random package") is somehow comparable (assuming no evil intentions). We know very little about the nature of the environment and its users to voice any definitive opinion here. In software development machines (with many competent users), it could make sense to allow users run their own software. Sometimes it is plain necessity (OpenWRT and OpenEmbedded that target embedded platforms will build from sources some tools needed to build the f/w image). –  FooF Feb 6 '13 at 5:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.