add easyconfigs for Scalasca, Score-P, Cube and dependencies

[boegel]

add easyconfigs for Scalasca, Score-P, Cube and dependencies (OPARI2, OTF(2), PDT, PAPI, binutils) + minor style fixes

these are contributed by @berndmohr via https://github.com/fgeorgatos/easybuild.experimental/tree/master/users/unite

this depends on easybuilders/easybuild-easyblocks#304 (and thus also on easybuilders/easybuild-framework#754)

[boegel]

@berndmohr: Your easyconfigs as pushed in https://github.com/fgeorgatos/easybuild.experimental/tree/master/users/unite can never work, because the dependency tree contains two versions of GCC (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/15/).

At first, I was very surprised, and wondered how this could have ever worked on your end. But then I looked into the AdaptedEBconfigs directory, and found this:

$ grep GCC users/unite/AdaptedEBconfigs/OpenMPI-1.6.5-GCC-4.8.1-no-OFED.eb 
toolchain = {'name': 'GCC', 'version': '4.7.3'}
$ grep '4\.' users/unite/AdaptedEBconfigs/gompi-1.5.12-no-OFED.eb
compver = '4.7.3'

So, although the file name for OpenMPI contains GCC-4.8.1, it's using GCC/4.7.3.
Just out of curiosity: what happened there? Is this related to the issues you had with getting the GCC build to work on your laptop during the hackathon (cfr. easybuilders/easybuild-easyblocks#283)?

I'll fix this by using gompi/1.4.10 for all these easyconfigs, which is probably the way of least resistance. gompi/1.4.10 uses GCC/4.7.2, while gompi/1.5.12 uses GCC/4.8.1. I've seen that GCC 4.8 is more strict than GCC 4.7 on a couple of occasions, so I won't loose time with fleshing out weird problems and use the same GCC family as you were using.

[boegel]

@berndmohr: I've also included the old versions of Scalasca, Cube, OPARI2, OTF in here.
Although they're old and obsolete, the builds work, so I don't see a reason not to include them (maybe someone out there has a very good reason to build a previous version, so we should allow to do that easily).
You've put the effort in for getting them to build, I don't want to let that go to waste.

[boegel]

@berndmohr: Ah, hold on, I think I know what happened... You started out building GCC/4.7.3, but then noticed that there only was a -no-OFED easyconfig for OpenMPI built on top of GCC/4.8.1. So you just tweaked the compiler version there and in gompi/1.5.12-no-OFED so you could continue... Is that correct?

[fgeorgatos]

Kenneth, watch out because Bernd's GCC has toolchainopts = {'pic': True}
Did you take that into account?

[boegel]

@fgeorgatos: Hah, no, missed that, thanks for the heads up.

[fgeorgatos]

I was about to make the same contrib this morning and then realized this;
then I went looking for a spare GCC 4.7.x to find the quick way out, but
alas :-P

In any case, some kind of variation in relation to the classic 4.7.3 seems
unavoidable.

On Sat, Nov 9, 2013 at 1:33 AM, Kenneth Hoste [email protected]:

@fgeorgatos https://github.com/fgeorgatos: Hah, no, missed that, thanks
for the heads up.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/505#issuecomment-28109528
.

[boegel]

@fgeorgatos: I'll need to figure out easybuilders/easybuild-easyblocks#293 first, because it seems like we've been building GCC on SL5 with -fPIC unintentionally for quite a while...

[berndmohr]

Explanation GCC 4.7.1: after the hackathon in Cyprus, I continued working on my office workstation which runs SuSe 12.3 (my laptop runs 12.2). On the workstation GCC 4.8.1 build successfully, but building other software with it, resulted in all kind of weird assembler errors - so to make quick progress I switched to GCC 4.7.3 but probably not the correct EasyBuild way ;-) I just took my exisiting EB files and changed manually every 4.8.1 to 4.7.3 -- guess I should have changed the gompi version too.

When I provided the EB files via the "experimental" repository, I understood that this is provided "AS-IS" without any guarantee about suitability and correctness; I tried hard to document and mark all out-standing issues

• lib/lib64 issues
• Qt and wxWidgets dependencies
• Extrae <=> binutils issue (GCC/binutils -fPIC)
• Not EB conform toolchain dependencies

It was my understanding that someone (Kenneth) who would want to move this into the normal EB distribution would fix the outstanding issues in the process , e.g. uploading verisons for the "standard" toolchain (goalf?) etc.

[boegel]

@bernd: Sure, I'm not trying to blame you for the fact that the easyconfigs don't work as expected when used 'in production', I fully understand that you cut corners (like not rebuilding GCC again) when playing around with EB.

The easyconfigs provided in easybuild.experimental should indeed be used with great care, which is perfectly OK.
I was just a bit surprised, and was trying to figure out what happened... It makes perfect sense in hindsight though.

I'm not that surprised that things went wrong when you tried using GCC/4.8.1, it's a lot more strict on various levels, and have seen things break that work fine with GCC 4.7.x a couple of times already.

I'll be tweaking your easyconfigs to gompi-1.4.12 (new toolchain) versions. I want to get rid of the GCC toolchain easyconfigs, because it clutters the easyconfig files too much (especially in the dependencies specs, which are mostly 4-tuples in your versions of the easyconfigs), but I don't want to 'blow them up' to full toolchains like goolf or such. If anyone wants to, they can do so very easily once these get it.

While I do that, I'll also see whether building GCC with -fPIC enabled is really required, because that a rather major change that may cause quite a bit of probems for others.

BTW: I am Kenneth, I was hoping my avatar speaks for itself. ;-)

[berndmohr]

I am actually reading the comments/messages through email (I gues I get them beause I "watch" the repositories, right?) and then it says, email from Kenneth Hoste ;-)

[boegel]

@berndmohr: Every time I 'tag' you using your GitHub login id, you'll get a mail (by default). If you watch the repositories, you should get mails for every opened PR/issue.

[boegel]

@berndmohr: I had to correct the sanity check paths for Cube. There's no binary bin/cube3 installed for Cube v3.4.3, but there are a bunch of cube3_x binaries. The documentation at http://apps.fz-juelich.de/scalasca/releases/cube/3.4/docs/CubeGuide.pdf seems to confirm this.
Are the corrections I added OK? Can you confirm that there shouldn't be a bin/cube3 available once the build completes?
I also fleshed out the qt4-devel OS dependency, I now provide the Qt provided by EasyBuild as a 'proper' dependency.

[fgeorgatos]

It seems that the same sources lead to different builds inside the bin directories, see below my case.

I think this is an example of build diversification due to environment/context?

fgeorgatos@e-cluster1-5:~$ ll /home/users/fgeorgatos/.local/easybuild/software/Cube/3.4.3-GCC-4.7.3/bin
total 11404
-rwxr-xr-x 1 fgeorgatos clusterusers    1969 Nov  6 09:31 cube-config
lrwxrwxrwx 1 fgeorgatos clusterusers      82 Nov  6 09:31 cube3 -> /home/users/fgeorgatos/.local/easybuild/software/Cube/3.4.3-GCC-4.7.3/bin/cube3-qt
-rwxr-xr-x 1 fgeorgatos clusterusers 1650100 Nov  6 09:31 cube3-qt
-rwxr-xr-x 1 fgeorgatos clusterusers  870679 Nov  6 09:31 cube3_clean
-rwxr-xr-x 1 fgeorgatos clusterusers  870425 Nov  6 09:31 cube3_cmp
-rwxr-xr-x 1 fgeorgatos clusterusers  874012 Nov  6 09:31 cube3_cut
-rwxr-xr-x 1 fgeorgatos clusterusers  871894 Nov  6 09:31 cube3_diff
-rwxr-xr-x 1 fgeorgatos clusterusers  871902 Nov  6 09:31 cube3_mean
-rwxr-xr-x 1 fgeorgatos clusterusers  872247 Nov  6 09:31 cube3_merge
-rwxr-xr-x 1 fgeorgatos clusterusers  874283 Nov  6 09:31 cube3_part
-rwxr-xr-x 1 fgeorgatos clusterusers  870530 Nov  6 09:31 cube3_remap
-rwxr-xr-x 1 fgeorgatos clusterusers  804774 Nov  6 09:31 cube3_score
-rwxr-xr-x 1 fgeorgatos clusterusers  750802 Nov  6 09:31 cube3_stat
-rwxr-xr-x 1 fgeorgatos clusterusers  713279 Nov  6 09:31 cube3_topoassist
-rwxr-xr-x 1 fgeorgatos clusterusers  754901 Nov  6 09:31 tau2cube3

[berndmohr]

@boegel: Something must go wrong with the QT configuration. Have you checked the configure output of Cube regarding Qt? The Cube data browser provides 2 parts: the CUBE format reader/writer libraries and format utilities (cube3_XXX) and the actual visual browser (cube3, which is actually a symlink to cube3-qt). As on the actual cluster only the first part is needed (to write CUBE files in performance measurements) and because Qt is typically not available on cluster compute nodes, Cube configure automatically builds the first part when no (suitable) Qt is found.

Your Qt configure options look good to me; but without seeing the configure output I cannot say what went wrong.

[berndmohr]

@boegel: Is there a "rule" or policy" how extensive the sanity_check should be? So far I used the "policy" to check for one important file in each of the installation directory subdirectories (bin/include/lib)?

[fgeorgatos]

On Sun, Nov 10, 2013 at 11:42 AM, berndmohr [email protected]:

@boegel https://github.com/boegel: Is there a "rule" or policy" how
extensive the sanity_check should be? So far I used the "policy" to check
for one important file in each of the installation directory subdirectories
(bin/include/lib)?

my crude ruleset about that is:

• it should be rich enough to capture potential failure modes of the build (any deviations MUST NOT trigger cascaded spurious failures in reverse dependencies)
• it does not (and should not) have to be too extensive, because that makes maintenance effort tricky and breaks across versions

I think the EB devs see it in a similar way

Also, to see the bigger picture, here is an almost related case (section of API missing from mkl):
#382

[berndmohr]

@boegel: The Cube (configure) behaviour brings up actually another question:
Should there be one or two EB components? The Scalasca and Score-P components technically only need the CUBE format library to build and function. Only later, if an user uses the package he/she very likely wants to actually look at the data, only in this case he/she needs the visual browser. Because of bad network connections, this is often executed on the users laptop/workstation (after copying the CUBE file locally) and not on the cluster (headnode). I guess we can leave it as is for now, but my team already made the decision to make the CUBE browser a stand-alone component -- it is just not implemented yet and will actually take a while.

[fgeorgatos]

about cube variations: perhaps needing a -bare and a full-fledged version?
Depends how you want it to break across different situations :)

[boegel]

I see no reason for a separate Cube build for now, since EB delivers everything. Don't forget: with a separate Cube build with Qt support, you wouldn't be able to load it into a session that already has the 'bare` Cube module loaded...

@berndmohr: The sanity check should be exhaustive enough to capture failures. In this case, it should check for cube3 (and/or cube-qt too) if the Qt dependency is present, otherwise we might miss it's not there (like we did now, I assumed the build was correct).
I'll try and figure out what went wrong, and will report back.

[boegel]

@berndmohr: I just rechecked, both the cube3-qt and cube3 symlink are there, so I don't know what I was thinking last night, but it worked like it should have. I'll fix the sanity checks for Cube v3.x to make sure that both are there.

[boegel]

Reworked the Score-P easyconfig to use the Score-P easyblock available in easybuilders/easybuild-easyblocks#304

[berndmohr]

@boegel: I understand now better the reasons why to implement Score-P as an easyblock and it is fine with me to get this into v1.9 as this looks like the most efficient / best working version regarding the features provided by v1.9.

However, this raises other issues: Scalasca 2.X and LWM2 use exactly the same GNU configure procedures
requiring configure options for the compiler and MPI library for a robust configuration (like Score-P) - so if you insist that an easyblock for Score-P is necessary, then the same argument calls for easyblocks for Scalasca-2 and LWM2. Scalasca-1 has a hand-written configure but acts the same way - so it would need an easyblock too. Otherwise, as you explained, a --try-toolchain=with something else than gompi, Score-P would work but creating an incompatible Scalasca-2 which requires Score-P as a dependency

[boegel]

@berndmohr: Score-P, Scalasca v2.x, OTF2, Cube 4.x (and also LWM2 in #510) are all using the EB_Score_minus_P easyblock available via easybuilders/easybuild-easyblocks#304; it was generalized a little bit to make it clear that it is used for multilple software packages (updated docstrings, kicked out the sanity_check_step that was specific to Score-P)

Scalasca v1.x now also has it's own easyblock, also available in easybuilders/easybuild-easyblocks#304 .

Everything was retested, and works like a charm, so I'm merging these in, in time for EasyBuild v1.9.

Please do review, even after the merge, and let me know if you have any remarks.

I'm very happy with how this turned out: a nice and clean solution that we can both agree on, and a bunch of new tools supported by EasyBuild (and more to come!).

[berndmohr]

@boegel: Regarding the patch for Cube 4.2 configure: is this a robustness improvement or something that was required to get it build with the latest Qt? Can you give some more background so I can open a ticket in the Cube repository?

[berndmohr]

@boegel: I am also very satisfied with the outcome with the "generic" Score-P component easyblock. It will provide a solid basis for the future enhancements and extensions in the Score-P toolset universe. Thanks for all your work (and patience)!

[fgeorgatos]

just a suggestion: since EB_Score_minus_P is shared among multiple UNITE builds,
wouldn't it be more appropriate to be considered generic style easyblock and get the name EB_UNITE or such?
I think this shows that it could be extended for further needs within the related set of tools...

[berndmohr]

@fgeorgatos: Kenneth and I discussed this: all the tools sharing the easyblock are components centered around the Score-P toolset (which use the the same set of GNU autoconfig modules). So we thought "Score-P component" or "Score-P" for short is appropriate. They all are build by the same group of people and are available on score-p.org.

UNITE would be wrong: UNITE also includes things like TAU or Paraver and their configure is not related at all with Score-P.

[fgeorgatos]

@berndmohr: ah, OK, that is a good explanation then;

it is also 2 commits to avoid and comment now does not disturb the (I guess) ongoing final build checks,
which Kenneth is assumed to be running before v1.9; in short, very well done.

[boegel]

@boegel: Regarding the patch for Cube 4.2 configure: is this a robustness improvement or something that was
required to get it build with the latest Qt? Can you give some more background so I can open a ticket in the Cube
repository?

@berndmohr: I just noticed I never answered this question...

The patch file I had to include for building Cube with a Qt provided by EasyBuild is required because determining the Qt version failed. The underlying problem was that Qt is installed to a path that includes version string(s), e.g. .../Qt/4.8.4-gompi-1.4.12-no-OFED/.
The qmake --version on which the Cube build-backend/configure script relies extracts the version with a regex, which fails because a string like ...Qt version 4.8.4 in <path> is printed. If the <path> contains versions, the regex fails.
By making the regex more strict, to make sure the actual Qt version is picked up, this problem is fixed.

So, long story short: it's a robustness improvement that should be included upstream probably, yes, it shouldn't break things (although I haven't checked the output of qmake --version on other Qt versions).

[berndmohr]

@boegel thanks for the update. we figured it out ourselves meanwhile. already fixed in Cube-4.2.1.