What is really required for installation?
 

I just installed the 32 bit OpenFOAM package on my workstation, as well as the third party package.

The environment variables to be configured in .bashrc broke my KDE4 installation so for the time I have removed that from .bashrc.

Also, I see that the third party stuff includes a couple of different versions of the gcc environment. This workstation contains a full-up development environment, and I really don't want to redirect any of that stuff to the OpenFOAM environment.

So my question(s) are as follows: 1. Why did the environment setup break KDE4 (I got the message that kstartupconfig4 was missing or had failed. Error code 1) and

2. What parts of 3rd party do I need and what can I remove, given that I don't want the gcc stuff?

Sorting this out manually could take a LOT of time, which I don't really have, and I'm sure that many people here already know the answer.

Thanks in advance.

Jim

The answer is fairly straightforward (although you didn't specify which distribution and which system gcc you normally have).

If we assume, for example, that your system has gcc-4.4.1 (like my openSUSE 11.2 system), but an older gcc is available - eg, gcc-4.3.3 from the ThirdParty-1.6.x.

When your kde4 (or some other system application) runs, it finds the libstdc++.so.6 from the LD_LIBRARY_PATH, which does not have the proper version - since it is from an older gcc!

You can check this with any C++ application. I'll take kwin, since you obviously have kde installed.

With the older gcc (from OpenFOAM) available via LD_LIBRARY_PATH:
yields a long list, but what interests us is the following:
If we then try the same thing with the default environment
we'll see that it can resolve all the interfaces.

There are a few different ways to handle this.

1. Don't source the OpenFOAM bashrc automatically, but use an alias to do it on-demand. This is the approach that we use. It is especially useful if you like to switch between versions or just like to have exact control over your environment. A corresponding 'noFoam' alias/function can be used to clean your PATH/LD_LIBRARY_PATH.
2. Upgrade the ThirdParty gcc to use a new version that will work well with your system. This is also the approach that we use. We currently use gcc-4.4.3 in the ThirdParty-1.6.x and have the compilation target set to linux64Gcc44DPOpt.

Of course, you can also just use the system compiler, but that may cause problems if you are running in parallel -- you'd need to ensure that each of your cluster nodes has a similarly new version of libstdc++.so.6 to match what you used on the workstation. Thus the OpenFOAM approach of bundling in a distinct gcc version within ThirdParty is definitely worth continuing to pursue, even if you decide to use upgrade that version itself.

OK. That makes sense. Thanks.

Seems to me that another alternative would be to download the source and compile it locally with the system compiler.

By the way, my system is Mandriva 2010 with gcc 4.4.1.