Hello,
There are several proprietary software that I need to use, and many of these depend on gcc 4.8.
For this reason, there are some systems I “froze” at LEAP 42.3, for personal reason (of completeness), I would like to be able to run these softwares on LEAP 15.0 and higher. There are several issues however mostly the fact that I am unaware which systems functions have a dependency for the default gcc bundled with the kernel and the OS.
To avoid conflicts or systems failure, I wish to create an environmental shell that inherits everything bash shell with the option of re-routing the bin and library addresses. For example, I’m thinking about setting up say
I have a few 32-bit programs that were compiled back in 2006 (running SuSE 10.1 at that time). And they still work as long as I install “glibc-32bit”.
As far as I know, C++ programs compiled with “gcc” will use libgcc. But most programs using plain C won’t really have any dependency on the compiler used. That is to say, they will still work, even if the install “gcc” is different. The main issue is with dynamically linked libraries. But you can usually have some control over this with settings for LD_LIBRARY_PATH and LD_RUN_PATH.
Okay,
In that case, I will first try setting the LD paths.
However in the future, I will need a shell that will need many older packages that are no longer supported. Is there a way to create a custom shell in that case?
If you look at “firefox” (as in “/usr/bin/firefox”), you will see that it is a shell script. It sets some environment variables, and then runs the real firefox executable. You can do something similar for other commands. Back when I was a sysadmin, I used to do that for some commands.
You should understand that typically an application is compiled once before you use it, and then never again. It’s very unusual for any app to have to be re-compiled more than once, much less repeatedly over a period of time.
Therefor,
The apps you compiled in 42.3 will be retained as you upgrade your openSUSE, perhaps all the way to the current 15.1 and they will continue to work… without any need or regard for any gcc installed on your system.
If you really needed to re-compile an application in any version of openSUSE using a gcc that isn’t default, I wrote a Wiki article how to set up your machine to switch between different gcc… Again, ordinarily unless your machine is re-compiling anything that requires gcc, you don’t care what is the default although I provide you guidance so you can switch between gcc easily
Some of the applications fail to compile with the new gcc version. Even if it does, I end up with segment fault possibly because of the some of the syntax and package headers that have been hard coded.
As for configuring update-alternatives for gcc. What I am looking for is almost what you have presented Tsu. I just wish to do that seperately in just one shell. Basically, I wish to create a new shell that inherits everything bash, and from there I can configure it to use gcc 4 for example using your instructions, but not actually affect the original bash, only the new shell.
I am sorry, but it eludes me complete what bash (or any shell) has to do with this.
The shell sits only between a terminal user and the kernel. It has no knowledge at all about which version of gcc is available, it does not even know anything about if gcc is a compiler or a game or whatever. It just reads from the terminal and tries to interprete that as a command. In the end it can be that the command is asking for starting a process from a file. While that file must be an executable (in being fit to be used as the code for a process), the shell has no knowledge about what that process will do.
Maybe I do misunderstand you, but I have the idea that others here also need some more explanation from you.
hcvv,
What I mean by creating a new shell environment is similar to bash, I would like to create a new shell environment which for the most part are duplicate of the existing system’s bash.
Now, in this environmental shell, I wish to by default use bin, library and etc. paths which would use a specific versions of the packages.
Similar to starting with bash, then re-setting
PATH, LD_LIBRARY_PATH, …
to specific directories such that my programs would run the way I would like them to.
I wish to do this for gcc for example since some of the proprietary software that I am trying to set up require a specific version of libraries within say libstdc++.so.6, and supplying sym link to a newer one would cause a segement fault. Similarly, the proprietary software specifically seeks for gcc48 and when it cannot, it will force a crash.
Before I start this software, I can export paths such that it would be forced to look into where I installed gcc48. Within that bash shell, everything seem to work okay, however I wish to create an entire shell to do this.
For example, similar to entering c or z shells and etc.
I wish to create for example, “48sh” such that when I open a terminal, I type in
48sh,
which would create reconfigure the paths so that I can avoid the conflicts altogether (as I am typing this, I am wondering to myself why I don’t bother just writing a shell script that would set the environment on demand).
I still think you are misunderstanding what the shell is and on the other side what the process environment (with it’s process environment variables) is.
Process environment variables (in short: environment variables) like PATH, LD_LIBRARY_PATH, … are not set by the shell, they are used by the shell. They are mostly set at the startup of a shell process because the shell at it’s start executes several files (if they exist) in a predefined sequence. Names like /etc/profile, ~/.profile, .bashrc, etc. are in this range. And when a user wants e.g. a PATH variable that differs from the default as configured by the system in /etc/profile, he can do so in his ~/.profile.
And the user can indeed call a script that changes PATH (and others) again, or type a command on the terminal that changes PATH, etc. The shell only uses what it finds as the value of PATH every time it uses it in the action of finding the file that corresponds to the first word of a command given (when that word does not contain a / and …).
From
man bash
PATH
The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below). A zero-length (null) directory name in the value of PATH indicates the current directory. A null directory name may appear as two adjacent colons, or as an initial or trailing colon. The default path is system-dependent, and is set by the administrator who installs bash. A common value is ``/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin’'.
And the other one you mention LD_LIBRARY_PATH is not even used by bash.
Well, as explained above, every user can set (and set them again and again) when he wants:
in his ~/.profile;
by typing the new values in a command line;
by putting the statement(s) in a file and “sourcing” them.
They are just NAME=VALUE pairs that you should export to the environment (the exporting is only needed once).
So either start a shell and when you want switch to the other environment “source” the file with statements.
Or, as gogalthorpe advises, use diferent users, each with the appropriate statments in their ~/.profile.
Or any combination you can imagine.
Oh, about the “sourcing”, which may be unknown to you.
Let us assume two two files:
That is a bit harsh. We, at the other end of this forum communication line, can not realy assess what your knowledge level is. I only took the trouble to type a lot of lines in trying to help you. My time is too precious to create “condescending comments”.
I assume that you now are able tohelp yourself with the details. Good luck.
hcvv,
I am grateful to your, and others’ comments on many topics. Not only this one but all of you helped me out more than once before. I just felt that it wasn’t necessary to assume that I don’t know how to source, script and etc. while the topic and previous statements I’ve made is about creating an entirely new shell similar to csh, zsh, and etc. which are beyond the knowledge or skill level of someone who cannot write a small environmental script.
Obviously from this thread, it’s totally unnecessary to create a new shell because we can just set up a profile for bash instead trying to create a new one which would be a lot more involved and time consuming. I admit, I had a brain fart, it was a dumb question.
I do appreciate your input, but I don’t always appreciate it if someone tells me that “about sourcing, which may be unknown to you”.