Thanks for these notes. FWIW - I don't see this issue on the CI MacOS boxes [2 Intel (default install of catalina, upgraded to ventura) , 1 M1 (montery, managed by admins)]
And I think it should be preferable to avoid these nasty scripts that keep modifying the firewall rules [per petsc binary, with sudo for each] - so if tweaking 'security' settings can accomplish that - and we should recommend it.] Satish On Fri, 28 Apr 2023, Samar Khatiwala wrote: > Hi, > > I realize this is an old thread but I have some recent experience based on > setting up an M2 Mac that might be relevant. > > I was dreading moving to Apple Silicon Macs because of issues like these but > I actually did not run into this particular problem. > While I can’t be certain I think it is because in the process of installing > another piece of software I had to modify Apple’s security > restrictions to make them more permissive. Details of how to do this are in > the following and it takes only a minute to implement: > > https://rogueamoeba.com/support/knowledgebase/?showArticle=ACE-StepByStep&product=Audio+Hijack > > Incidentally, I built mpich from source followed by PETSc in the usual way. > > Something else that might be helpful for others is my experience getting > ifort to work. (My needs were somewhat specific: mixed > fortran/C code, preferably ifort, and avoid package managers.) The intel > OneAPI installer ran smoothly (via rosetta) but when > building mpich (or PETSc) I ran into an obvious problem: clang produces arm64 > object files while ifort produces x86 ones. I couldn’t > manage to set the correct CFLAGS to tell clang to target x86. Instead, the > (simpler) solution turned out to be (1) the fact that all the > executables in Apple’s toolchain are universal binaries, and (2) the ‘arch’ > command can let you run programs for any of the two > architectures. Specifically, executing in the terminal: > > arch -x86_64 bash > > starts a bash shell and *every* program that is then run from that shell is > automatically the x86 version. So I could then do: > FC=ifort > ./configure --prefix=/usr/local/mpichx86 --enable-two-level-namespace > make > sudo make install > > and get an x86 build of mpich which I could then use (from the same shell or > a new one started as above) to build [x86] PETSc. > Except for some annoying warnings from MKL (I think because it is confused > what architecture it is running on) everything runs > smoothly and - even in emulation - surprisingly fast. > > Sorry if this is all well know and already documented on PETSc’s install page. > > Samar > > On Mar 20, 2023, at 6:39 AM, Pierre Jolivet > <[email protected]<mailto:[email protected]>> wrote: > > > On 20 Mar 2023, at 2:45 AM, Barry Smith > <[email protected]<mailto:[email protected]>> wrote: > > > I found a bit more information in gmakefile.test which has the magic sauce > used by make test to stop the firewall popups while running the test suite. > > # MACOS FIREWALL HANDLING > # - if run with MACOS_FIREWALL=1 > # (automatically set in $PETSC_ARCH/lib/petsc/conf/petscvariables if > configured --with-macos-firewall-rules), > # ensure mpiexec and test executable is on firewall list > # > ifeq ($(MACOS_FIREWALL),1) > FW := /usr/libexec/ApplicationFirewall/socketfilterfw > # There is no reliable realpath command in macOS without need for 3rd party > tools like homebrew coreutils > # Using Python's realpath seems like the most robust way here > realpath-py = $(shell $(PYTHON) -c 'import os, sys; > print(os.path.realpath(sys.argv[1]))' $(1)) > # > define macos-firewall-register > @APP=$(call realpath-py, $(1)); \ > if ! sudo -n true 2>/dev/null; then printf "Asking for sudo password to > add new firewall rule for\n $$APP\n"; fi; \ > sudo $(FW) --remove $$APP --add $$APP --blockapp $$APP > endef > endif > > and below. When building each executable it automatically calls > socketfilterfw on that executable so it won't popup. > > From this I think you can reverse engineer how to turn it off for your > executables. > > Perhaps PETSc's make ex1 etc should also apply this magic sauce, Pierre? > > This configure option was added in > https://gitlab.com/petsc/petsc/-/merge_requests/3131 but it never worked on > my machines. > I just tried again this morning a make check with MACOS_FIREWALL=1, it’s > asking for my password to register MPICH in the firewall, but the popups are > still appearing afterwards. > That’s why I’ve never used that configure option and why I’m not sure if I > can trust this code from makefile.test, but I’m probably being paranoid. > Prior to Ventura, when I was running the test suite, I manually disabled the > firewall https://support.apple.com/en-gb/guide/mac-help/mh11783/12.0/mac/12.0 > Apple has done yet again Apple things, and even if you disable the firewall > on Ventura > (https://support.apple.com/en-gb/guide/mac-help/mh11783/13.0/mac/13.0), the > popups are still appearing. > Right now, I don’t have a solution, except for not using my machine while the > test suite runs… > I don’t recall whether this has been mentioned by any of the other devs, but > this is a completely harmless (though frustrating) message: MPI and/or PETSc > cannot be used without an action from the user to allow others to get access > to your machine. > > Thanks, > Pierre > > On Mar 19, 2023, at 8:10 PM, Amneet Bhalla > <[email protected]<mailto:[email protected]>> wrote: > > This helped only during the configure stage, and not during the check stage > and during executing the application built on PETSc. Do you think it is > because I built mpich locally and not with PETSc? > > On Sun, Mar 19, 2023 at 3:51 PM Barry Smith > <[email protected]<mailto:[email protected]>> wrote: > > ./configure option with-macos-firewall-rules > > > On Mar 19, 2023, at 5:25 PM, Amneet Bhalla > <[email protected]<mailto:[email protected]>> wrote: > > Yes, this is MPI that is triggering the apple firewall. If I allow it it gets > added to the allowed list (see the screenshot) and it does not trigger the > firewall again. However, this needs to be done for all executables (there > will be several main2d's in the list). Any way to suppress it for all > executables linked to mpi in the first place? > > <Screenshot 2023-03-19 at 2.19.53 PM.png> > > On Sun, Mar 19, 2023 at 11:01 AM Matthew Knepley > <[email protected]<mailto:[email protected]>> wrote: > On Sun, Mar 19, 2023 at 1:59 PM Amneet Bhalla > <[email protected]<mailto:[email protected]>> wrote: > I'm building PETSc without mpi (I built mpich v 4.1.1 locally). Here is the > configure command line that I used: > > ./configure --CC=mpicc --CXX=mpicxx --FC=mpif90 --PETSC_ARCH=darwin-dbg > --with-debugging=1 --download-hypre=1 --with-x=0 > > > No, this uses MPI, it just does not built it. Configuring with --with-mpi=0 > will shut off any use of MPI, which is what Satish thinks is bugging the > firewall. > > Thanks, > > Matt > > On Sun, Mar 19, 2023 at 10:56 AM Satish Balay > <[email protected]<mailto:[email protected]>> wrote: > I think its due to some of the system calls from MPI. > > You can verify this with a '--with-mpi=0' build. > > I wonder if there is a way to build mpich or openmpi - that doesn't trigger > Apple's firewall.. > > Satish > > On Sun, 19 Mar 2023, Amneet Bhalla wrote: > > > Hi Folks, > > > > I'm trying to build PETSc on MacOS Ventura (Apple M2) with hypre. I'm using > > the latest version (v3.18.5). During the configure and make check stage I > > get a request about accepting network connections. The configure and check > > proceeds without my input but the dialog box stays in place. Please see the > > screenshot. I'm wondering if it is benign or something to be concerned > > about? Do I need to accept any network certificate to not see this dialog > > box? > > > > Thanks, > > > > > > > > -- > --Amneet > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/> > > > -- > --Amneet > > > > > > > -- > --Amneet > >
