Re: [easybuild] GCCcore-11.3.0.eb: system gcc too old
On top of what Åke mentioned (I have no idea how you managed to install GCC 2.20, that's beyond ancient...), you can always consider using an older GCC module as a build dependency when building GCCcore, via a hook for example (see https://docs.easybuild.io/hooks/) But in this particular case, you should really figure out why you're not seeing GCC 4.8 as default GCC in CentOS 7... regards, Kenneth On 22/09/2023 07:29, Åke Sandgren wrote: On a CentOS7.9 system the system GCC should be 4.8.5 and that has no problem building GCC 11.3.0 GCC 2.2 was used back in the days of CentOS 4 or so From: easybuild-requ...@lists.ugent.be on behalf of Loris Bennett Sent: Thursday, September 21, 2023 16:09 To: easybuild Subject: [easybuild] GCCcore-11.3.0.eb: system gcc too old Hi, Up until recently we had a homogenous cluster and built software for a single microarchitecture. We now have new nodes with different CPUs need to rebuild a large number of packages. However, rebuilding GCCcore-11.3.0.eb is failing with the following error: configure: error: *** A compiler with support for C++11 language features is required. The system GCC is 2.20 (it is a CentOS 7.9 machine). On the same machine it was apparently possible to build GCCcore-11.3.0.eb in the past. So do I now have to build an older GCCcore, which EasyBuild can then subsequently use to build 11.3.0, or how do I get around this issue? Cheers, Loris -- Dr. Loris Bennett (Herr/Mr) ZEDAT, Freie Universität Berlin
AW: AW: [easybuild] Installing EasyBuild as 'generic' architecture?
Dear Loris, > I hadn't thought about dealing with SYSTEM-modules separately. How does this > work when you build an > architecture-dependent, piece of software with a specific toolchain and > '--robot', but which has a dependency which > uses the SYSTEM-toolchain? Everything will be installed in the same > architecture-dependent subdirectory, won't it? This is in fact a downside of not exposing the SYSTEM-branch of the modules tree in the MODULEPATH. You need to identity all the modules with the SYSTEM-toolchain and install them separately. Once, only modules with GCCcore or higher toolchains are missing, you can use --robot. But once you have installed a few modules, you usually have all the SYSTEM-modules you need linked to an hpc-env so that --robot detects these as existing modules. > PS: See you in Oldenburg at the AK Supercomputing, maybe? Since we organize the meeting, yes Best wishes Stefan -- Scientific Computing Carl von Ossietzky University Oldenburg School of Mathematics and Natural Sciences 26111 Oldenburg, Germany Office: W03 1-139 Phone: +49-441-798 3147 E-Mail: stefan.har...@uni-oldenburg.de www: http://www.uni-oldenburg.de/fk5/wr -Ursprüngliche Nachricht- Von: easybuild-requ...@lists.ugent.be Im Auftrag von Loris Bennett Gesendet: Freitag, 22. September 2023 09:16 An: easybuild@lists.ugent.be Betreff: Re: AW: [easybuild] Installing EasyBuild as 'generic' architecture? ACHTUNG! Diese E-Mail kommt von Extern! WARNING! This email originated off-campus. Dear Stefan, "Dr. Stefan Harfst" writes: > Dear Loris, > > will you not overwrite the existing module if you use --force? > I.e. the module will always point to the software directory of the > architecture you have build last. I am mounting the directory on each nodes with the architecture-specific software under /sw/sc/easybuild with each node mounting the correct branch of the NFS directory for its CPU. But as you say, --force will overwrite modules, so I need to be able to load EasyBuild separately from the other software. > We have done something similar and yes, we treat EasyBuild itself > differently. I will try to outline our setup: > * we have a basepath /cm/shared/uniol > * in the basepath we have modules and sw > * initially, our module path only consists of > /cm/shared/uniol/modules/core in this path we put the EasyBuild > modules and modules we call hpc-env > * if you load hpc-env/ the module path is extended with paths > like /cm/shared/uniol///, where can be zen3, > zen4, ice, sky or so. is actually referring to the GCCcore > version but this is not so relevant. are the module classes like > bio, chem and so on > * the hpc-env module uses an environment variable to know which is the > architecture of the current node, so it shows only that part of the > module tree This is an approach that I have seen used elsewhere. My thinking in using the mount approach instead was that the users don't have to load an extra module and that the modules don't have some slightly arbitrary path, such as '/cm/shared/' (or in our case it is actually '/trinity/shared/') baked into the 'root' variable. > * the sw-directory has the same structure, so .../sw// and > we use --subdir-modules and --subdir-software to install the software > and module in the right paths (we have setup an alias that also > identifies from the env variable) > * we also have a SYSTEM arch for everything build with toolchain = > SYSTEM (../sw/SYSTEM and correspondingly ../modules/SYSTEM), we link > the SYSTEM-modules into all / (hidden, if there is > non-SYSTEM version) I hadn't thought about dealing with SYSTEM-modules separately. How does this work when you build an architecture-dependent, piece of software with a specific toolchain and '--robot', but which has a dependency which uses the SYSTEM-toolchain? Everything will be installed in the same architecture-dependent subdirectory, won't it? > * Easybuild itself is installed directly in sw but it could also go into > SYSTEM (or your generic). OK, so treating EasyBuild differently from the bulk of the software seems indeed to be way to go. > It means that you need a lot of space and every module is installed > several times, but you are only reusing a working Easyconfig and it > can be somewhat automatized. We are already resigned to the fact that a lot of space will be needed, but it looks this sort of approach is the only way to ensure that each node will see software that will definitely run on it. > > Hope this helps. Thanks for the detailed explanation of your approach. Cheers, Loris PS: See you in Oldenburg at the AK Supercomputing, maybe? > Best wishes > Stefan > > -- > Scientific Computing > > Carl von Ossietzky University Oldenburg School of Mathematics and > Natural Sciences > 26111 Oldenburg, Germany > > Office: W03 1-139 > Phone: +49-441-798 3147 > E-Mail: stefan.har...@uni-oldenburg.de > www:
Re: AW: [easybuild] Installing EasyBuild as 'generic' architecture?
Hi Alan,
Alan O'Cais writes:
> Just to mention, an approach like Stefans does not necessarily mean
> users have to load another module to get access to software. For
> users, you only care about where the software for the architecture
> lives. In the default profile you can define this with, e.g.,:
>
> export
> DEFAULT_ARCHITECTURE_MODULEPATH=${SITE_EB_PREFIX}/${ARCH_SUBDIR}/modules/core
> module use ${DEFAULT_ARCHITECTURE_MODULEPATH}
>
> where ${SITE_EB_PREFIX} is common to all archs and ${ARCH_SUBDIR}
> needs to be defined/derived for each architecture.
>
> Then, developers could still use `hpc-env/` modules if those
> include the Lmod/Tmod equivalent of `module unuse
> ${DEFAULT_ARCHITECTURE_MODULEPATH}` at the beginning.
Thanks for pointing that out. I thought I was going to have to
reinstall EasyBuild itself in the 'generic' path, but since this is a
subdirectory of =${SITE_EB_PREFIX} it seems easier to
do something like
export EB_MODULEPATH=${SITE_EB_PREFIX}/modules
module use ${EB_MODULEPATH}
where
${SITE_EB_PREFIX}/modules
essentially just contains EasyBuild and then have
export
DEFAULT_ARCHITECTURE_MODULEPATH=${SITE_EB_PREFIX}/${ARCH_SUBDIR}/modules/core
module use ${DEFAULT_ARCHITECTURE_MODULEPATH}
for the architecture-specific software.
The drawback of this is, however, that I will still have the problem of
having to use '--force' and then remove the non-architecture-specific
packages once the corresponding architecture-specific packages have been
build. However, maybe I can get around that with a bit of creative soft
linking.
Cheers,
Loris
> Alan
>
> On 22-Sep-23 9:15 AM, Loris Bennett wrote:
>> Dear Stefan,
>>
>> "Dr. Stefan Harfst" writes:
>>
>>> Dear Loris,
>>>
>>> will you not overwrite the existing module if you use --force?
>>> I.e. the module will always point to the software directory of the
>>> architecture you have build last.
>> I am mounting the directory on each nodes with the architecture-specific
>> software under
>>
>>/sw/sc/easybuild
>>
>> with each node mounting the correct branch of the NFS directory for its
>> CPU. But as you say, --force will overwrite modules, so I need to be
>> able to load EasyBuild separately from the other software.
>>
>>> We have done something similar and yes, we treat EasyBuild itself
>>> differently. I will try to outline our setup:
>>> * we have a basepath /cm/shared/uniol
>>> * in the basepath we have modules and sw
>>> * initially, our module path only consists of
>>> /cm/shared/uniol/modules/core in this path we put the EasyBuild
>>> modules and modules we call hpc-env
>>> * if you load hpc-env/ the module path is extended with paths
>>> like /cm/shared/uniol///, where can be zen3,
>>> zen4, ice, sky or so. is actually referring to the GCCcore
>>> version but this is not so relevant. are the module classes
>>> like bio, chem and so on
>>> * the hpc-env module uses an environment variable to know which is
>>> the architecture of the current node, so it shows only that part of
>>> the module tree
>> This is an approach that I have seen used elsewhere. My thinking in
>> using the mount approach instead was that the users don't have to load
>> an extra module and that the modules don't have some slightly arbitrary
>> path, such as '/cm/shared/' (or in our case it is actually
>> '/trinity/shared/') baked into the 'root' variable.
>>
>>> * the sw-directory has the same structure, so .../sw//
>>> and we use --subdir-modules and --subdir-software to install the
>>> software and module in the right paths (we have setup an alias that
>>> also identifies from the env variable)
>>> * we also have a SYSTEM arch for everything build with toolchain =
>>> SYSTEM (../sw/SYSTEM and correspondingly ../modules/SYSTEM), we
>>> link the SYSTEM-modules into all / (hidden, if there is
>>> non-SYSTEM version)
>> I hadn't thought about dealing with SYSTEM-modules separately. How does
>> this work when you build an architecture-dependent, piece of software
>> with a specific toolchain and '--robot', but which has a dependency
>> which uses the SYSTEM-toolchain? Everything will be installed in the
>> same architecture-dependent subdirectory, won't it?
>>
>>> * Easybuild itself is installed directly in sw but it could also go into
>>> SYSTEM (or your generic).
>> OK, so treating EasyBuild differently from the bulk of the software seems
>> indeed to be way to go.
>>
>>> It means that you need a lot of space and every module is installed
>>> several times, but you are only reusing a working Easyconfig and it
>>> can be somewhat automatized.
>> We are already resigned to the fact that a lot of space will be needed,
>> but it looks this sort of approach is the only way to ensure that each
>> node will see software that will definitely run on it.
>>
>>> Hope this helps.
>> Thanks for the detailed explanation of your approach.
>>
>> Cheers,
>>
>> Loris
>>
>> PS: See you in Oldenburg at the AK Supercomputing, maybe?
>>
>>> Best wishes
Re: AW: [easybuild] Installing EasyBuild as 'generic' architecture?
Just to mention, an approach like Stefans does not necessarily mean
users have to load another module to get access to software. For users,
you only care about where the software for the architecture lives. In
the default profile you can define this with, e.g.,:
export
DEFAULT_ARCHITECTURE_MODULEPATH=${SITE_EB_PREFIX}/${ARCH_SUBDIR}/modules/core
module use ${DEFAULT_ARCHITECTURE_MODULEPATH}
where ${SITE_EB_PREFIX} is common to all archs and ${ARCH_SUBDIR} needs
to be defined/derived for each architecture.
Then, developers could still use `hpc-env/` modules if those
include the Lmod/Tmod equivalent of `module unuse
${DEFAULT_ARCHITECTURE_MODULEPATH}` at the beginning.
Alan
On 22-Sep-23 9:15 AM, Loris Bennett wrote:
Dear Stefan,
"Dr. Stefan Harfst" writes:
Dear Loris,
will you not overwrite the existing module if you use --force?
I.e. the module will always point to the software directory of the
architecture you have build last.
I am mounting the directory on each nodes with the architecture-specific
software under
/sw/sc/easybuild
with each node mounting the correct branch of the NFS directory for its
CPU. But as you say, --force will overwrite modules, so I need to be
able to load EasyBuild separately from the other software.
We have done something similar and yes, we treat EasyBuild itself differently.
I will try to outline our setup:
* we have a basepath /cm/shared/uniol
* in the basepath we have modules and sw
* initially, our module path only consists of /cm/shared/uniol/modules/core in
this path we put the EasyBuild modules and modules we call hpc-env
* if you load hpc-env/ the module path is extended with paths like
/cm/shared/uniol///, where can be zen3, zen4, ice, sky or so.
is actually referring to the GCCcore version but this is not so relevant. are the module classes like bio,
chem and so on
* the hpc-env module uses an environment variable to know which is the
architecture of the current node, so it shows only that part of the module tree
This is an approach that I have seen used elsewhere. My thinking in
using the mount approach instead was that the users don't have to load
an extra module and that the modules don't have some slightly arbitrary
path, such as '/cm/shared/' (or in our case it is actually
'/trinity/shared/') baked into the 'root' variable.
* the sw-directory has the same structure, so .../sw// and we use
--subdir-modules and --subdir-software to install the software and module in the right paths (we
have setup an alias that also identifies from the env variable)
* we also have a SYSTEM arch for everything build with toolchain = SYSTEM (../sw/SYSTEM and
correspondingly ../modules/SYSTEM), we link the SYSTEM-modules into all
/ (hidden, if there is non-SYSTEM version)
I hadn't thought about dealing with SYSTEM-modules separately. How does
this work when you build an architecture-dependent, piece of software
with a specific toolchain and '--robot', but which has a dependency
which uses the SYSTEM-toolchain? Everything will be installed in the
same architecture-dependent subdirectory, won't it?
* Easybuild itself is installed directly in sw but it could also go into SYSTEM
(or your generic).
OK, so treating EasyBuild differently from the bulk of the software seems
indeed to be way to go.
It means that you need a lot of space and every module is installed
several times, but you are only reusing a working Easyconfig and it
can be somewhat automatized.
We are already resigned to the fact that a lot of space will be needed,
but it looks this sort of approach is the only way to ensure that each
node will see software that will definitely run on it.
Hope this helps.
Thanks for the detailed explanation of your approach.
Cheers,
Loris
PS: See you in Oldenburg at the AK Supercomputing, maybe?
Best wishes
Stefan
--
Scientific Computing
Carl von Ossietzky University Oldenburg
School of Mathematics and Natural Sciences
26111 Oldenburg, Germany
Office: W03 1-139
Phone: +49-441-798 3147
E-Mail: stefan.har...@uni-oldenburg.de
www: http://www.uni-oldenburg.de/fk5/wr
-Ursprüngliche Nachricht-
Von: easybuild-requ...@lists.ugent.be Im
Auftrag von Loris Bennett
Gesendet: Donnerstag, 21. September 2023 17:12
An: easybuild
Betreff: [easybuild] Installing EasyBuild as 'generic' architecture?
ACHTUNG! Diese E-Mail kommt von Extern! WARNING! This email originated
off-campus.
Hi,
EasyBuild plus all our software built with EasyBuild is currently installed
under
/nfs/easybuild/software/EasyBuild
However, I am reinstalling software compiled for different microarchitectures
in a directory structure which looks like the following:
/nfs/easybuild/arch
├── generic
└── x86_64
├── amd
│ └── zen3
└── intel
├── cascadelake
└── skylake_avx512
At the moment I am essentially using something like
eb --prefix=/nfs/easybuild/arch/x86_64/intel/cascadelake --force ...
to
Re: AW: [easybuild] Installing EasyBuild as 'generic' architecture?
Dear Stefan, "Dr. Stefan Harfst" writes: > Dear Loris, > > will you not overwrite the existing module if you use --force? > I.e. the module will always point to the software directory of the > architecture you have build last. I am mounting the directory on each nodes with the architecture-specific software under /sw/sc/easybuild with each node mounting the correct branch of the NFS directory for its CPU. But as you say, --force will overwrite modules, so I need to be able to load EasyBuild separately from the other software. > We have done something similar and yes, we treat EasyBuild itself > differently. I will try to outline our setup: > * we have a basepath /cm/shared/uniol > * in the basepath we have modules and sw > * initially, our module path only consists of /cm/shared/uniol/modules/core > in this path we put the EasyBuild modules and modules we call hpc-env > * if you load hpc-env/ the module path is extended with paths like > /cm/shared/uniol///, where can be zen3, zen4, ice, sky > or so. is actually referring to the GCCcore version but this is not so > relevant. are the module classes like bio, chem and so on > * the hpc-env module uses an environment variable to know which is the > architecture of the current node, so it shows only that part of the module > tree This is an approach that I have seen used elsewhere. My thinking in using the mount approach instead was that the users don't have to load an extra module and that the modules don't have some slightly arbitrary path, such as '/cm/shared/' (or in our case it is actually '/trinity/shared/') baked into the 'root' variable. > * the sw-directory has the same structure, so .../sw// and we use > --subdir-modules and --subdir-software to install the software and module in > the right paths (we have setup an alias that also identifies from the > env variable) > * we also have a SYSTEM arch for everything build with toolchain = SYSTEM > (../sw/SYSTEM and correspondingly ../modules/SYSTEM), we link the > SYSTEM-modules into all / (hidden, if there is non-SYSTEM version) I hadn't thought about dealing with SYSTEM-modules separately. How does this work when you build an architecture-dependent, piece of software with a specific toolchain and '--robot', but which has a dependency which uses the SYSTEM-toolchain? Everything will be installed in the same architecture-dependent subdirectory, won't it? > * Easybuild itself is installed directly in sw but it could also go into > SYSTEM (or your generic). OK, so treating EasyBuild differently from the bulk of the software seems indeed to be way to go. > It means that you need a lot of space and every module is installed > several times, but you are only reusing a working Easyconfig and it > can be somewhat automatized. We are already resigned to the fact that a lot of space will be needed, but it looks this sort of approach is the only way to ensure that each node will see software that will definitely run on it. > > Hope this helps. Thanks for the detailed explanation of your approach. Cheers, Loris PS: See you in Oldenburg at the AK Supercomputing, maybe? > Best wishes > Stefan > > -- > Scientific Computing > > Carl von Ossietzky University Oldenburg > School of Mathematics and Natural Sciences > 26111 Oldenburg, Germany > > Office: W03 1-139 > Phone: +49-441-798 3147 > E-Mail: stefan.har...@uni-oldenburg.de > www: http://www.uni-oldenburg.de/fk5/wr > > -Ursprüngliche Nachricht- > Von: easybuild-requ...@lists.ugent.be Im > Auftrag von Loris Bennett > Gesendet: Donnerstag, 21. September 2023 17:12 > An: easybuild > Betreff: [easybuild] Installing EasyBuild as 'generic' architecture? > > ACHTUNG! Diese E-Mail kommt von Extern! WARNING! This email originated > off-campus. > > Hi, > > EasyBuild plus all our software built with EasyBuild is currently installed > under > > /nfs/easybuild/software/EasyBuild > > However, I am reinstalling software compiled for different microarchitectures > in a directory structure which looks like the following: > > /nfs/easybuild/arch > ├── generic > └── x86_64 > ├── amd > │ └── zen3 > └── intel > ├── cascadelake > └── skylake_avx512 > > At the moment I am essentially using something like > > eb --prefix=/nfs/easybuild/arch/x86_64/intel/cascadelake --force ... > > to rebuild modules. However, at some point I will want to avoid using > '--force', but IIUC that will mean that I have to 'unuse' the original module > path > > /nfs/easybuild/software/EasyBuild/modules > > in order to build modules which already exist in the > non-architecture-specific path. This in turn, since EasyBuild module itself > is in that path, would deactivate the EasyBuild module. > > Does that mean I have to reinstall EasyBuild under > > /nfs/easybuild/arch/generic > > which I guess would be the most consistent solution, or is there an > alternative? > > Cheers, > > Loris > > -- > Dr.
