{lib}[GCC/6.4.0-2.28,GCCcore/6.4.0] libsigsegv v2.11, libsigsegv v2.11#4840
Conversation
…1-GCCcore-6.4.0.eb
|
In the past, there seems there was an issue with --minimal-toolchains using GCC (vs GCCcore) when building with the "intel" toolchain. I stuck with GCCcore in our last 2017A (based on 2017a) toolchains. I don't care either way (though the GCC one is easier since I don't have to include the binutils). As long as it will be found by intel/iomkl./foss toolchains (I don't need a version for each). Note, we have a flat module naming system here (not hierarchical) so am not sure of the overall impact. What is the preference between the two that allow me to reuse across all toolchains? |
…ay or may not be entirely sane)
|
@JackPerdue There's a known issue when easyconfigs with
I do agree that having to include |
|
boegel 3:03 PM hiya siliconslick! siliconslick 3:09 PM howdy! Any guidance to offer on EC PR#4840? i.e. GCC vs GCCcore for use across toolchains boegel 3:26 PM @siliconslick Haven't had time to look into that one yet. Maybe related to the issue @vanzod opened though: easybuilders/easybuild-framework#2265 boegel 4:06 PM @siliconslick reviewed your PR #4840 vanzod 4:09 PM @siliconslick I always operate under the paradigm of building with the lowest possible toolchain. The only exception to this rule is when building math libraries (e.g. NLopt). In such cases, although I could build them under GCCcore, I prefer to build them with the GCC and iccifort toolchains in order to take advantage of the different level of optimization that a compiler can provide wrt the other. siliconslick 4:59 PMI guess thats for the sake of intel to make sure it finds the iccifort one and not reach all the way down to GCCcore... I would think the optimizations of GCC and GCCcore (no intel) would be same vanzod 5:31 PM @siliconslick Well, if you use --minimal-toolchain if you have both iccifort and GCCcore, it will pick the latter. So it is important to have only the GCC and iccfort available siliconslick 5:32 PM That complicates things... instead of a nice simple "easy" heuristic like "use GCCcore unless you need MPI or linear algebra(MKL)" tosomething like...."well, depending whether the package would benefit from Intel optimiazations you might want to use GCC instead (to cooperate with intel toolchain)"..... then there is the question of what packages to go which way with 5:34 If I submit an easyconfig using GCCcore do you have a way later to ignore the easyconfigs from EB in your robot path? e.g. only consider built tools on the system so far (and not EB) 5:40 PM e.g. will --use-existing-modules help in those cases if there is a GCCcore version in the EB repo? I know I've been confused by that option in the past so am not sure. 5:41 e.g. I commit GCCcore for now but if you want to come along later and add the GCC ver and then only build that one on your system (???) </end Slack> |
|
@JackPerdue With @vanzod's point of sometimes preferring |
|
@JackPerdue If you delete one of the two files, I can proceed with the merging process. |
going with GCCcore for now
|
|
||
| description = """ | ||
| GNU libsigsegv is a library for handling page faults in user mode. | ||
| """ |
There was a problem hiding this comment.
Please merge description in a single line.
| toolchain = {'name': 'GCCcore', 'version': '6.4.0'} | ||
|
|
||
| source_urls = [GNU_SOURCE] | ||
| sources = [SOURCELOWER_TAR_GZ] |
|
Test report by @vanzod |
|
Going in, thanks @JackPerdue! |
(created using
eb --new-pr)ligsigsegv - GCC or GCCcore if I want to use with intel/2017b??