Results 1 to 4 of 4
I'm currently using RHEL 5.5, which is distributed with gcc 4.1.2. I installed Matlab 8.0 which supports gcc 4.4.x. I am also attempting to use an executable that was built ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 12-26-2012 #1
- Join Date
- Dec 2012
Multiple versions of gcc on the system
I'm currently using RHEL 5.5, which is distributed with gcc 4.1.2. I installed Matlab 8.0 which supports gcc 4.4.x. I am also attempting to use an executable that was built on a system running RHEL 5.5 (gcc 4.1.2) and Matlab 7 (with supports a previous version of gcc, seemingly 4.1.x). At run time, i get an error stating something like "/blabla_path/some_user_developed_exe: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.9' not found (required by /usr/local/MATLAB/R2012b/bin/glnxa64/libmx.so)". So, my version of MATLAB is not finding some things it needs in the libstdc++.so library. I get similar incompatiblility type messages when i try to compile the original source code with my version (4.1.2) of gcc.
At this point, since libstdc++.so is a pointer, i could download a more recent version of the file that it points to and (logging in as root) change the pointer. This **should** fix the runtime issues. But now i have a hybrid version of gcc (and i just don't like that idea). But the better way to do this is to install the correct version of gcc.
I REALLY want to leave my gcc 4.1.2 in place, but my reasons may not be sound (i've been told to leave the compiler the kernel was built on in place, plus i'm concerned with backwards compatibility). I know i can install the gcc 4.4.x with the "--program-transform-name" rpm option (though i've never used that option) and the "--prefix" option to change the install location. Then, since i have all of the source code for the executable i'm trying to run, i can modify the supplied MakeFile to call the newer version of gcc. This is where my lack of knowledge of shared libraries and library management is bogging me down. I think this will fix the compile time issues (maybe). I may need to use the -rpath option or set the LD_RUN_PATH enviro variable, but i'm unsure of this. But my bigger concern is how the system will resolve the runtime access to the correct version of the libstdc++.so library. Perhaps i need to set the LD_LIBRARY_PATH enviro variable for runtime issues. But again, i'm unsure of this.
So now that you know my delima and my knowledge (or lack thereof) of the situation, i'm hoping someone can step in and clear up the ambiguities or suggest a better way of handling this.
Last edited by geezmaneti; 12-26-2012 at 02:50 PM.
- 12-29-2012 #2
- Join Date
- May 2011
Hello and welcome!
To distill down your question to something simpler to digest: you have one version of gcc (that came with your OS) and you want to have another version available for compiling. Yes?
If so, then I would leave the original gcc in place, and grab the gcc tarball from GNU's website and compile it from scratch, using the --prefix switch to configure to tell it to install somewhere other than /usr (where your system's default gcc is installed). Two common paths used are /usr/local (for the purists) and /opt/gcc-x.x.x (for the control freaks).
Then when you want to compile using the newer compiler, define the CC, LDFLAG, CFLAGS and any other relevant env vars first, and you should be good. It is handy to have a script you can source, before compiling with the newer compiler.
When you need to run a program compiled with the newer (or any, really) compiler, your executable has the dynamically linked library information in it and will look for those files when the executable is run. To that end, you may need to define LD_LIBRARY_PATH before running the executable. You can use "ldd /path/to/your/prog.exe" to see what libraries have been linked to the program.
- 12-31-2012 #3
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
You can install multiple versions of GCC on a system. The non-standard ones should be named things like gcc44, where the default gcc 4.1 will still be gcc. If you can install the newer compiler with yum, do so as that will enforce this naming convention. Installing from source may overwrite the standard 4.1 gcc.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 01-02-2013 #4
- Join Date
- Dec 2012
Great responses guys/gals and very easy to understand. Thank you very much!