@geimer: the only change that raises a question for me is this one...

There must have been a good reason we're using get_software_libdir here?

@boegel: There was no good reason; it simply was a bug that went by unnoticed for quite some time. I've checked all Score-P releases back to v1.1 (Oct 2012) and the configure option always worked like this:

  --with-libbfd=(yes|no|<Path to libbfd installation>)
                          If you want to build with libbfd support but do not
                          have a libbfd in a standard location, you need to
                          explicitly specify the directory where it is
                          installed. On non-cross-compile systems we search
                          the system include and lib paths per default [yes];
                          on cross-compile systems, however, you have to
                          specify a path [no]. --with-libbfd is a shorthand
                          for --with-libbfd-include=<Path/include> and
                          --with-libbfd-lib=<Path/lib>. If these shorthand
                          assumptions are not correct, you can use the
                          explicit include and lib options directly.
  --with-libbfd-include=<Path to libbfd headers>
  --with-libbfd-lib=<Path to libbfd libraries>

That is, some absolute path of libbfd.a was passed in, the configure check tried to use it as a prefix for 'include' and 'lib', this obviously didn't help in making the compile/link check pass, and the compiler adapter fell back to using nm instead of libbfd. configure prints a big fat warning that the provided path does not exist, but it is so well hidden in the EB log file that basically nobody finds it...

@geimer: That sounds very reasonable, but... We're missing something.

On top of current develop, all builds using this Score_minus_P easyblock work fine; that includes: Cube (v4.x), LWM2, OTF2, Scalasca and Score-P itself.

On top of this updated easyblock however, two of the Score-P builds fail (Score-P-1.2.1-gompi-1.4.12-no-OFED.eb and Score-P-1.2.3-goolf-1.5.14.eb), while another one works fine Score-P-1.4-foss-2015a.eb... The other stuff using this easyblock works fine (Cube (v4.x), LWM2, OTF2, Scalasca).

So, it seems like we've introduced some kind of regression for Score-P 1.2.x?

Here's the relevant error message (reformatted for readability):

 == 2016-05-13 18:58:24,165 build_log.py:152 ERROR cmd " ./configure --prefix=...  --with-libbfd=$EBROOTBINUTILS " exited with exitcode 1 and output: 
...
checking bfd.h usability... yes                                                                                                                                                                                                                                           
checking bfd.h presence... yes                                                                                                                                                                                                                                            
checking for bfd.h... yes                                                                                                                                                                                                                                                 
: error: cannot find libbfd.a, libbfd.so, or libbfd.dylib                                                                                                                                                                                                                 
configure: error: ./configure failed for build-mpi  

Note that without this patch, it's not the absolute path of libbfd.a being passed, but the path to the directory in which libbfd.a resides, i.e. --with-libbfd=$EBROOTBINUTILS/lib.

This apparently works with Score-P 1.2.x and 1.4 (despite it being wrong according to the help info for --with-libbfd vs --with-libbfd-lib.

@geimer The original PR for the Score-P easyblock (#304) mentions the need for specifying the lib subdir for --with-libbfd (and --with-papi-lib) rather than specifying the root, so it seems like we did have a good reason for this...

Could this have been a bug in the handling of --with-libbfd option in Score 1.2.x, and this behaviour being retained as a fallback in later versions for backward compatibility?

Maybe @berndmohr remembers why we needed to specify the path to the /lib subdirectory of the binutils install directory rather than the root install prefix as suggested with the help output for --with-libbfd?

My suggestion would be to put a version check in place for versions older than Score-P 1.4, and stick to using the /lib approach for those, to avoid breaking stuff?

@geimer: this workaround does the job for me: geimer#4