Make PETSc build on macOS Sierra with GCC by eschnett · Pull Request #1835 · spack/spack

eschnett · 2016-09-23T13:57:16Z

Don't set cpp when building on Darwin.

davydden · 2016-09-23T14:10:04Z

var/spack/repos/builtin/packages/petsc/package.py

 # License along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 ##############################################################################
+


don't need a new line here

Seems nice to have it -- there's a long copyright message above, and the import statements are rather short in comparison, and are not related to the copyright statement in any way.

it is not there in pretty much any package.py. So for consistency i would not add it.

davydden · 2016-09-23T14:11:53Z

var/spack/repos/builtin/packages/petsc/package.py

                '--with-mpi=1',
                '--with-mpi-dir=%s' % self.spec['mpi'].prefix,
            ]
+        if sys.platform != "darwin":


why is that change? PETSc builds perfectly fine for me on Sierra and same was on ElCapitan?

The problem is that Spack's cpp doesn't work. I'm building first gcc (6.2) via Spack, then use this gcc to build other packages. Apparently gcc's cpp doesn't work on Sierra with certain system header files. Similar issues have existed with gcc on Darwin for a long time, so I didn't investigate details but instead simply reverted to letting PETSc choose the cpp it naturally wants. I don't have the exact error message handy any more.

it certainly worked for me with ElCapitan and gcc from Spack, i will quickly try gcc now...

btw, if this is Sierra only + gcc isse, the if should reflect this fact. It certainly builds fine with clang on Sierra! See #1814. For now I would at least suggest combining

mac_ver = '.'.join(py_platform.mac_ver()[0].split('.')[:2])

with

if spec.satisfies('%gcc')

Turning this off for all builds on darwin does not look right to me.

@tgamblin is there a variable in Spack which holds version of OS to be used in conditionals inside package.py?

here is the if:

if (sys.platform == "darwin") and (spec.satisfies('%gcc')) and (spec.architecture.platform_os.version == "10.12"):

I'm running OSX El Capitan and have spack at 462a4a1, building with clang + gfortran. I've hit this bug and have also found that I've had to remove the

'--with-cpp=cpp', '--with-cxxcpp=cpp',

lines to get PETSc to build. I'm not sure why I have troubles building this while @davydden doesn't. Apart from his upgraded system, we have pretty much the same setup.

@jppelteret i suppose you are on Sierra?

@eschnett would you mind adding (spec.architecture.platform_os.version == "10.12") to your if?

Given extra feedback, i agree that this should be fixed to make things work.

davydden · 2016-09-23T14:14:05Z

it builds on darwin[1] already (both with clang and gcc), please provide more details of what is the problem?

[1] ElCapitan.

davydden · 2016-09-23T14:35:20Z

cant reproduce the issue as m4 fails to build for me on Sierra with gcc 6.2.0

In file included from ./spawn.h:37:0,
                 from execute.c:47:
./sched.h:42:8: error: redefinition of 'struct sched_param'
 struct sched_param
        ^~~~~~~~~~~
In file included from ./sched.h:27:0,
                 from ./spawn.h:37,
                 from execute.c:47:
/usr/include/sched.h:35:8: note: originally defined here
 struct sched_param { int sched_priority;  char __opaque[__SCHED_PARAM_SIZE__]; };
        ^~~~~~~~~~~
depbase=`echo fopen-safer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
    /Users/davydden/spack/lib/spack/env/gcc/gcc  -I.   -I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include  -g -O2 -MT fopen-safer.o -MD -MP -MF $depbase.Tpo -c -o fopen-safer.o fopen-safer.c &&\
    mv -f $depbase.Tpo $depbase.Po

So it could be that gcc is indeed broken. But then i would not even touch PETSc as this is a workaround, but not a cure for the problem.

eschnett · 2016-09-23T15:09:13Z

The problem I encountered has nothing to do with m4. There are many packages that don't build with gcc on Darwin, and I build these with the system clang instead. I even used to have an automatic mechanism for this in these packages, but the consensus was that such breakage is best avoided by putting respective compiler specs on the command line.

You will have to write spec install petsc %gcc ^m4 %clang or similar. Your actual command line will be more complicated, because you need to make sure that all C++ code is built with gcc, not with clang, since the C++ libraries on Darwin are incompatible between these. You will need to check what dependencies of PETSc Spack wants to build with clang, and will have to explicitly choose gcc for these. Conversely, if any of the build dependencies don't build with gcc, you will have to manually select clang for these.

davydden

i talked ot @jppelteret and he had this issue indeed on ElCapitan. I don't know what is going on here and why i never had this issue on ElCapitan, but let's merge this.

@tgamblin ping.

Make PETSc build on Darwin

b674781

Don't set cpp when building on Darwin.

davydden suggested changes Sep 23, 2016

View reviewed changes

adamjstewart mentioned this pull request Sep 23, 2016

M4 installation fail on macOS sierra with GCC #1838

Closed

davydden changed the title ~~Make PETSc build on Darwin~~ Make PETSc build on macOS Sierra with GCC Sep 23, 2016

davydden approved these changes Sep 26, 2016

View reviewed changes

davydden added macOS new-package ready labels Sep 26, 2016

tgamblin merged commit 88af9f7 into spack:develop Sep 26, 2016

eschnett deleted the eschnett/petsc-darwin branch September 27, 2016 15:29

tgamblin mentioned this pull request Oct 11, 2016

[xSDK] PETSc review #1999

Closed

Conversation

eschnett commented Sep 23, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davydden Sep 23, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davydden commented Sep 23, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davydden commented Sep 23, 2016

Uh oh!

eschnett commented Sep 23, 2016

Uh oh!

davydden left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

davydden Sep 23, 2016 •

edited

Loading

davydden commented Sep 23, 2016 •

edited

Loading