Comilation stage : gcc dependencies error

[sirlb]

Hello,

I installed CS with a gcc which is compiled with dependencies that are in non standard path.
The installation succeed and then I use the Module tool to load gcc, openmpi, python matching code_saturne installation.

Some computations succeed when not using user source file needing compilation.

Now I am trying to run a computation that need to compile user source file and have an error regarding gcc dependencies not found :

Code: Select all

/home/applis/compil/gcc450/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951: error while loading shared libraries: libcloog.so.0: cannot open shared object file: No such file or directory
gfortran -I /toto/RESU/20140317-1401/src_saturne -I /home/applis/code_saturne/3.2.1/gcc-4.5.0/include/code_saturne -x f95-cpp-input -Wall -O -c /toto/RESU/20140317-1401/src_saturne/cs_user_extra_operations.f90

I guess that the CS script that make the compilation is overriding the path set by my gcc module.
How can I fix this issue ?

[Yvan Fournier]

Hello,

Did you load some modules after installation ? If this is the case, you should load them before starting the install.

If you are using environment modules, Code_Saturne should detect active modules at install time, and purge all modules then reload those detected at install when running, so you should not have this problem.

We do have issues if you are using a very old version of the "modules" command, which does not support Python (for some reason I am not aware of, this is the case on the Curie supercomputer, for example). In this case, you may force the configuration to ignore modules by adding "--with-modules=no", then load the modules in your runcase file (or for a more "global" post-install solution, source a file containing the apropriate commands in a file referenced as rcfile in Code_Saturne's <install_prefix>/etc/code_saturne.cfg file).

Best regards,

Yvan

[sirlb]

Thank you for your reply.

I finally found that the version of module tool installed on the cluster had some bug that overrides LD_LIBRARY PATH instead of the normal prepending operation.

With a newer version of module, everything is now ok.

Thanks for your help.