specify default compiler tool chain

[cekees]

On os x we (@malej,@ahmadia) are seeing mpich fail to build because of apparently incompatible compilers available in the path set up in osx.yaml on some systems. We need to do something to be more explicit about the default compiler toolchain. Here is the error on the system with intel and gnu compilers in /usr/bin:

checking whether Fortran 77 compiler accepts option -O2... no
checking how to get verbose linking output from ifort... -v
checking for Fortran 77 libraries of ifort...  -L/usr/bin/ifort-11.1-base/lib -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/ -L/usr/lib/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../ /usr/bin/ifort-11.1-base/lib/libifport.a /usr/bin/ifort-11.1-base/lib/libifcore.a /usr/bin/ifort-11.1-base/lib/libimf.a /usr/bin/ifort-11.1-base/lib/libsvml.a /usr/bin/ifort-11.1-base/lib/libipgo.a -lSystemStubs -lmx /usr/bin/ifort-11.1-base/lib/libirc.a -lpthread -ldl
checking whether ifort accepts the FLIBS found by autoconf... no
checking for valid entries in FLIBS... 
checking whether gcc links with FLIBS found by autoconf... yes
checking whether Fortran 77 and C objects are compatible... no
checking for file... file
configure: error: Could not determine a way to link a Fortran test program!
make: *** No targets specified and no makefile found.  Stop.
checking for linker for Fortran main program... 
Command '[u'/bin/bash', '_hashdist/build.sh']' returned non-zero exit status 2
command failed (code=2); raising

[certik]

Yeah, that needs to be fixed.

[malej]

So, as discussed earlier today it's fair to say that on OS X (10.8 at least) if you have any other compiler suites in your /usr/local/ and do not specify exactly which compiler tool chain you are using specifically in osx.yaml issues will arise all over the place. So, here's the content of my $HOME/proteus/stack/osx.yaml:

extends:
- file: common.yaml

parameters:
    platform: Darwin
    PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
    PROLOGUE: |
    export MACOSX_DEPLOYMENT_TARGET=$(sw_vers -productVersion | sed "s/\(10.[0-9]\).*/\1/");export CC=/usr/bin/gcc;export CXX=/usr/bin/g++;export FC=/usr/local/bin/gfortran;export F77=/usr/local/bin/gfortran

This did the job for me and make check for serial and parallel went fine.

[ahmadia]

Excellent. I'm a little surprised that the compilers were interfering, since they should have been on the path behind the compilers in /usr/bin. I'm guessing that maybe some of the frameworks defaulted to the location where all three compilers could be found?

Regardless, I don't think it's a bad idea to export these compilers in our default examples.

On Thu, Jan 16, 2014 at 7:32 PM, Matt Malej notifications@github.comwrote:

So, as discussed earlier today it's fair to say that on OS X (10.8 at least) if you have any other compiler suites in your /usr/local/ and do not specify exactly which compiler tool chain you are using specifically in osx.yaml issues will arise all over the place. So, here's the content of my $HOME/proteus/stack/osx.yaml:

extends:

• file: common.yaml

parameters: platform: Darwin PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin PROLOGUE: | export MACOSX_DEPLOYMENT_TARGET=$(sw_vers -productVersion | sed "s/(10.[0-9]).*/\1/");export CC=/usr/bin/gcc;export CXX=/usr/bin/g++;export FC=/usr/local/bin/gfortran;export F77=/usr/local/bin/gfortran

This did the job for me and make check for serial and parallel went fine.

— Reply to this email directly or view it on GitHubhttps://github.com/hashdist/hashstack2/issues/108#issuecomment-32568275 .

[cekees]

In Matt's case, at least for mpich, the problem compiler seems like it was in /usr/bin/ifort, which it was picking up instead of /usr/local/bin/gfortran. I was surprised that the intel compilers were installed in /usr/bin, but that's what it showed in his build.log.

On Thu, Jan 16, 2014 at 6:34 PM, Aron Ahmadia notifications@github.comwrote:

Excellent. I'm a little surprised that the compilers were interfering, since they should have been on the path behind the compilers in /usr/bin. I'm guessing that maybe some of the frameworks defaulted to the location where all three compilers could be found?

Regardless, I don't think it's a bad idea to export these compilers in our default examples.

On Thu, Jan 16, 2014 at 7:32 PM, Matt Malej notifications@github.comwrote:

So, as discussed earlier today it's fair to say that on OS X (10.8 at least) if you have any other compiler suites in your /usr/local/ and do not specify exactly which compiler tool chain you are using specifically in osx.yaml issues will arise all over the place. So, here's the content of my $HOME/proteus/stack/osx.yaml:

extends:

• file: common.yaml

parameters: platform: Darwin PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin PROLOGUE: | export MACOSX_DEPLOYMENT_TARGET=$(sw_vers -productVersion | sed "s/(10.[0-9]).*/\1/");export CC=/usr/bin/gcc;export CXX=/usr/bin/g++;export FC=/usr/local/bin/gfortran;export F77=/usr/local/bin/gfortran

This did the job for me and make check for serial and parallel went fine.

— Reply to this email directly or view it on GitHub< https://github.com/hashdist/hashstack2/issues/108#issuecomment-32568275> .

— Reply to this email directly or view it on GitHubhttps://github.com/hashdist/hashstack2/issues/108#issuecomment-32568373 .

[ahmadia]

Okay, that makes sense. Anyway, let's leave this issue open for a bit while we consider our options for implementing this. I like the idea of specifying the compilers.