[petsc-dev] CMake on Catalina

[Satish Balay]

Yeah - there as prior e-mail on OSX discrepancies.

Note all 3 boxes are on 10.15 - and Xcode-11+. Is 10.14 SDK a reference to Xcode-10?

Satish
---

balay at jpro^~ $ xcodebuild -version
Xcode 11.3.1
Build version 11C504

The other tow boxes are now giving:
ipro:~ balay$ xcodebuild -V
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
balay at kpro ~ % xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance


ipro:~ balay$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.59)
balay at jpro^~ $ clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
balay at kpro ~ % clang --version
Apple clang version 11.0.0 (clang-1100.0.33.8)


Satish

On Sat, 18 Apr 2020, Pierre Jolivet wrote:

> This looks similar to last month message "[petsc-maint] GNU toolchain on macOS”, you probably need to go back to the 10.14 SDK.
> 
> Thanks,
> Pierre
> 
> > On 18 Apr 2020, at 3:59 AM, Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> > 
> > I just did the following build on 3 of the OSX test boxes. [with brew gcc etc..]
> > 
> > balay at jpro^~/petsc(maint) $ ./configure --with-mpi=0 CC=gcc-9 CXX=g++-9 FC=gfortran-9 --download-cmake
> > 
> > Worked on 2 of them.
> > 
> > The 3rd failed with PETSc configure errors.
> > 
> > As far as I can tell - all 3 systems should be the same [latest, OSX, xcode updated at the same time, all have command line tools installed etc..] - but they are not  - and I don't understand why.
> > 
> > Satish
> > 
> > ---------
> > 
> > ================================================================================
> > TEST checkLibC from config.setCompilers(/Users/balay/petsc/config/BuildSystem/config/setCompilers.py:1510)
> > TESTING: checkLibC from config.setCompilers(config/BuildSystem/config/setCompilers.py:1510)
> >  Test whether we need to explicitly include libc in shared linking
> >       - Mac OSX requires an explicit reference to libc for shared linking
> > Running Executable WITHOUT threads to time it out
> > Executing: gcc-9 -c -o /var/folders/xk/v0fd809s2y7b3x8bp05l2nww0000gq/T/petsc-GRzCKQ/config.setCompilers/conftest.o -I/var/folders/xk/v0fd809s2y7b3x8bp05l2nww0000gq/T/petsc-GR\
> > zCKQ/config.setCompilers   /var/folders/xk/v0fd809s2y7b3x8bp05l2nww0000gq/T/petsc-GRzCKQ/config.setCompilers/conftest.c 
> > Possible ERROR while running compiler: exit code 1
> > stderr:
> > In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:110,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> >                 from /var/folders/xk/v0fd809s2y7b3x8bp05l2nww0000gq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h: In function 'getiopolicy_np':
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:443:34: error: expected declaration specifiers before '__OSX_AVAILABLE_STARTING'
> >  443 | int     getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
> >      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:449:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__OSX_AVAILABLE_STA\
> > RTING'
> >  449 | int     setiopolicy_np(int, int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
> >      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libkern/_OSByteOrder.h:66,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/_endian.h:130,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/i386/endian.h:99,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/machine/endian.h:35,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:186,
> >                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> >                 from /var/folders/xk/v0fd809s2y7b3x8bp05l2nww0000gq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> > ....
> > 
> > On Fri, 17 Apr 2020, Matthew Knepley wrote:
> > 
> >> CMake itself. On Catalina, the SSL/TLS headers use special syntax that only
> >> Clang can parse.
> >> You should check for this in the configure stage, but they do not. The
> >> response for the error
> >> reports on the CMake Github was that you should not be building on Apple
> >> with something that
> >> won't parse some of the Apple headers. This seems like an abdication of
> >> responsibility to me.
> >> 
> >>   Matt
> >> 
> >> On Fri, Apr 17, 2020 at 7:07 PM Satish Balay <balay at mcs.anl.gov> wrote:
> >> 
> >>> Build cmake or a package using cmake?
> >>> 
> >>> balay at sb /home/balay/petsc (master=)
> >>> $ grep download-cmake config/examples/arch-ci-osx-*
> >>> config/examples/arch-ci-osx-cxx-cmplx-pkgs-dbg.py:  '--download-cmake=1',
> >>> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> >>> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> >>> config/examples/arch-ci-osx-xsdk-opt.py:  '--download-cmake=1',
> >>> 
> >>> download-cmake works fine on all our OSX test boxes [they are on Catalina]
> >>> 
> >>> balay at kpro petsc % sw_vers
> >>> ProductName:    Mac OS X
> >>> ProductVersion: 10.15.3
> >>> BuildVersion:   19D76
> >>> 
> >>> And I have cmake installed via brew on these boxes.
> >>> 
> >>> Satish
> >>> 
> >>> On Fri, 17 Apr 2020, Matthew Knepley wrote:
> >>> 
> >>>> I have just spent hours trying to build CMake on Catalina. This is not a
> >>>> configure system. I finally had to just comment out a bunch of source
> >>> files
> >>>> in their build system, and define out a bunch of code. I can't believe
> >>> this
> >>>> works anywhere.
> >>>> 
> >>>>   Matt
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
>