On 17/08/15 18:08, Kenneth Hoste wrote: > Hi Chris,
Hiya, > On 17/08/15 07:47, Christopher Samuel wrote: > >> It turns out that if you try and build GCC 4.9.2 on a Haswell box with >> --with-arch=native then the build fails because the assembler in RHEL6.7 >> doesn't understand some of the instructions GCC emits. > > Yes, see also > https://github.com/hpcugent/easybuild-easyconfigs/issues/1605 . Thanks - good to know we're not the first. :-) >> Apparently these are supported by binutils-2.25 and I can see that there >> is a GCC-4.9.2-binutils-2.25.eb present in EB but the toolchains don't >> use that. > > Yet. The foss/2015b toolchain (now in develop, to be included in > EasyBuild 2.2.1 (or 2.3.0) going out soon) does use it (or rather, it > uses the update GCC-4.9.3-binutils-2.25.eb instead). We're hitting it when trying to built the intel & iomkl toolchains as it wants to build GCC and we want all GCC builds to support the native instruction set (otherwise no point in investing in these chips). >> Is there any better way of getting any GCC build to use a version with >> binutils-2.25 other than to copy all the GCC eb's and then edit them to >> include a dependency on binutils-2.25? > > Well, you can just include binutils as a dependency in the GCC > easyconfig itself (without renaming it), that will work too. [...] I might be missing something, but I think that's what I was wondering if there was a way to avoid doing (you'd need to do each GCC eb file to be sure). > This is > basically what we do in the 2015b toolchains, via the (new) subtoolchain > named GNU (which bundles GCC with binutils). > > Or you could go with foss/2015b instead (not sure what you're using now). We're currently on: This is EasyBuild 2.2.0 (framework: 2.2.0, easyblocks: 2.2.0) [...] Unfortunately fixing it there is too high up the dependency chain to help other toolchains that depend directly on a specific GCC version. >> We did see --amend/--try-amend with versionsuffix=-binutils-2.25 but >> instead of adding that onto the GCC-4.9.2.eb when resolving dependencies >> it seems to just build GCC-4.9.2.eb as >> GCC-4.9.2-binutils-2.25.eb (but without the newer binutils) which is the >> opposite of what we're trying to achieve. > > WIth --amend=versionsuffix=-foo, you're telling EasyBuild: please look > for an easyconfig that has 'versionsuffix=-foo' that otherwise matching > the one I'm specifying. This should result in GCC-4.9.2-binutils-2.25.eb > being picked up (with the binutils dep included). Hmm, not sure I'm doing that right then as it doesn't appear to do that here: [samuel@snowy-m ~]$ eb GCC-4.9.2.eb --amend=versionsuffix=-binutils-2.25 -D -r == temporary log file in case of crash /dev/shm/eb-f409Ov/easybuild-XBSYfL.log Dry run: printing build status of easyconfigs and dependencies CFGS=/usr/local/easybuild/software/EasyBuild/2.2.0/lib/python2.6/site-packages/easybuild_easyconfigs-2.2.0-py2.6.egg/easybuild/easyconfigs/g/GCC * [ ] $CFGS/GCC-4.9.2.eb (module: GCC/4.9.2) == temporary log file(s) /dev/shm/eb-f409Ov/easybuild-XBSYfL.log* have been removed. == temporary directory /dev/shm/eb-f409Ov has been removed. strace reveals that it stat()'s GCC-4.9.2-binutils-2.25.eb but never opens it. Running with debug reveals: [...] == 2015-08-18 09:50:36,327 main.EasyConfig DEBUG Obtained specs dict {'versionsuffix': '-binutils-2.25'} == 2015-08-18 09:50:36,327 main.EasyConfig INFO Parsing easyconfig file /usr/local/easybuild/software/EasyBuild/2.2.0/lib/python2.6/site-packages/easybuild_easyconfigs-2.2.0-py2.6.egg/easybuild/easyconfigs/g/GCC/GCC-4.9.2.eb with rawcontent: name = "GCC" [...] So it seems to understand the argument, but doesn't use it. > With --try-amend=versionsuffix=-foo, you're telling EasyBuild: please > modify the specified easyconfig by including "versionsuffix = '-foo'" > before building it. But this does not imply changing the list of > dependencies. OK, thanks for that. > Something like this *may* work, if you really want to refrain from > copying and modifying the GCC-4.8.2.eb easyconfig file manually: > > eb GCC-4.8.2.eb --try-amend="dependencies=,('binutituls', '2.25')" Sadly not.. $ eb GCC-4.8.2.eb --try-amend="dependencies=,('binutituls', '2.25')" -D -r == temporary log file in case of crash /dev/shm/eb-YqHjsM/easybuild-O5jnRZ.log ERROR: Can't find path /vlsci/VLSCI/samuel/'2.25') > If this doesn't work as expected, just copy the GCC-4.8.2.eb easyconfig > and include this: dependencies = [('binutils', '2.25')] Yeah, I think the best we can do is to do that for every single easybuild. But this is turning into a lot of patchwork that has to be forward ported on each upgrade, and I'm starting to think this might be something we don't have the resources to get into right now. > Note that I'm not touching the versionsuffix here, since that would > imply you need to use --try-toolchain-version=4.8.2-binutils-2.25 over > and over again. Understood. > Instead, I'm just assuming you're OK with installing GCC/4.8.2 with a > minor site customization, i.e. including a newer binutils version as a > dependency. That's correct - though of course you'd want to do that for all GCC's just to cover your bases. >> Shame this only popped up now but the test system I've had to play with >> was Sandybridge and (unsurprisingly) that was supported fine in RHEL6. > > Bad test system. ;-) Not really its fault, it was something that was delivered in 2012 that was for this sort of dev & test work, not a system that was meant to be representative of our new cluster. All the best, Chris -- Christopher Samuel Senior Systems Administrator VLSCI - Victorian Life Sciences Computation Initiative Email: [email protected] Phone: +61 (0)3 903 55545 http://www.vlsci.org.au/ http://twitter.com/vlsci
