Hi Fotis, Thanks. That may be fine if you are building your entire installation with Easybuild. But here we already have an installed base (stable, with a number of older versions), and I would like to use Easybuild for extra, or bleeding-edge versioned software.
So the next thought is how to let users know which modules they will need to unload (for the dependencies of the module they load). Any ideas? Todd From: Fotis Georgatos <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> List-Post: [email protected] Date: Thursday, January 30, 2014 at 10:39 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [easybuild] module unload for toolchains? Dear Todd, On Jan 30, 2014, at 4:33 PM, Heywood, Todd wrote: Details: I have built Python3 for the goalf toolchain: Python/3.2.5-goalf-1.5.12-no-OFED. This uses GCC 4.8.1, while our “default” GCC is older. If someone with other software build with our ‘default” installations wants to use Python3, they would do “module unload Python/3.2.5-goalf-1.5.12-no-OFED” after their program finishes. But the newer GCC 4.8.1 remains in the environment, and their other software may crash since it was built with and older GCC (libraries). At the moment, we consider this more of a feature than a bug: you take the pain of unloading the modules if you really intend to try the ABI compatibility between different modules. The approach that we all take is, to stick to 2-3 toolchains and build all the relevant modules for them... Then, we encourage users to pick early on their toolchain "space" and, then potential compatibility issues are greatly reduced. best, Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # Yelling in a CERN forum
