#29404 closed defect (fixed)
Fix build failures of pynac on macos with system python3
Reported by:  Matthias Köppe  Owned by:  

Priority:  blocker  Milestone:  sage9.1 
Component:  packages: standard  Keywords:  
Cc:  Dima Pasechnik, François Bissey, Vincent Delecroix, Julian Rüth, Isuru Fernando, Erik Bray  Merged in:  
Authors:  Matthias Koeppe  Reviewers:  Dima Pasechnik 
Report Upstream:  Completely fixed; Fix reported upstream  Work issues:  
Branch:  7344e2d (Commits, GitHub, GitLab)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
https://github.com/mkoeppe/sage/runs/531095486
pynac:
checking whether sagepython23 version is >= 2.7... yes checking for sagepython23 version... 3.7 checking for sagepython23 platform... darwin checking for sagepython23 script directory... ${prefix}/lib/python3.7/sitepackages checking for sagepython23 extension module directory... ${exec_prefix}/lib/python3.7/sitepackages checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands c and o together... yes checking dependency style of gcc... none checking for python3.7... no configure: error: Cannot find python3.7 in your system path
Fix in https://github.com/pynac/pynac/pull/351, https://github.com/mkoeppe/pynac/releases/tag/pynac0.7.26.sage20200328
The "temporary upstream" tarball URL is in checksums.ini
. To test the update on this branch: Use make SAGE_SPKG="sagespkg o" pynacclean pynac
; this will download the new upstream package automatically.
Attachments (1)
Change History (77)
comment:1 Changed 3 years ago by
Cc:  Dima Pasechnik added 

comment:2 Changed 3 years ago by
Cc:  François Bissey added 

Summary:  Fix build failures of pplpy on macos with system python3 → Fix build failures of pplpy and pynac on macos with system python3 
comment:3 followup: 21 Changed 3 years ago by
Cc:  Vincent Delecroix added 

This should be probably split into two tickets.
pplpy upstream is https://gitlab.com/videlec/pplpy  also in CC:
comment:4 followup: 17 Changed 3 years ago by
Yes for the split. I am surprised that problem shows now in pynac. I would have expected it to happen much earlier. The AX_PYTHON_DEVEL macro is 5 years old  which probably doesn't help.
comment:5 Changed 3 years ago by
Note that I don't think the problem is in the macro, but something in there may trigger. I suspect the problem is in AM_PATH_PYTHON
and that PYTHON
needs to be defined when calling configure in spkginstall
.
comment:6 Changed 3 years ago by
Which is already done. So I am not sure what happens to override it. Access to config.log would be helpful.
comment:8 followup: 9 Changed 3 years ago by
It looks from the log as here could be some mixing up happening between system python3 and Homebrew's python3 (unless Homebrew's python3 is using system's python3 headers by design).
comment:9 Changed 3 years ago by
Replying to dimpase:
It looks from the log as here could be some mixing up happening between system python3 and Homebrew's python3 (unless Homebrew's python3 is using system's python3 headers by design).
Shouldn't happen. We pass PYTHON=sagepython23
explicitly to configure. That's what should be tested.
https://github.com/sagemath/sage/blob/develop/build/pkgs/pynac/spkginstall.in#L14
My gut feeling is that something funny happened to that line during processing. But I need config.log to establish it.
comment:10 Changed 3 years ago by
I don't have MacOS machine, but anyone with it may install Homebrew and try.
comment:11 Changed 3 years ago by
It is more subtle than my implied gut feeling. The macro AX_PYTHON_DEVEL gets the right value for PYTHON and does its stuff based on that. I think AM_PATH_PYTHON
doesn't like python with exotic names because it looks like it goes through a predefined list.
comment:12 Changed 3 years ago by
isn't the location of Sage's Python exotic enough to choke it, if it were the case?
comment:13 Changed 3 years ago by
It would be :)
Code inspection says I have it backwards. AM_PATH_PYTHON
works and AX_PYTHON_DEVEL
is the one failing.
comment:14 Changed 3 years ago by
Toxic. This is with an old sage I have around
[pynac0.7.14] checking whether sagepython23 version is >= 2.7... yes [pynac0.7.14] checking for sagepython23 version... 2.7 [pynac0.7.14] checking for sagepython23 platform... linux2 [pynac0.7.14] checking for sagepython23 script directory... ${prefix}/lib/python2.7/sitepackages [pynac0.7.14] checking for sagepython23 extension module directory... ${exec_prefix}/lib/python2.7/sitepackages [pynac0.7.14] checking for style of include used by make... GNU [pynac0.7.14] checking for gcc... gcc [pynac0.7.14] checking whether the C compiler works... yes [pynac0.7.14] checking for C compiler default output file name... a.out [pynac0.7.14] checking for suffix of executables... [pynac0.7.14] checking whether we are cross compiling... no [pynac0.7.14] checking for suffix of object files... o [pynac0.7.14] checking whether we are using the GNU C compiler... yes [pynac0.7.14] checking whether gcc accepts g... yes [pynac0.7.14] checking for gcc option to accept ISO C89... none needed [pynac0.7.14] checking whether gcc understands c and o together... yes [pynac0.7.14] checking dependency style of gcc... gcc3 [pynac0.7.14] checking for python2.7... /home/fbissey/sagemath/sage/local/bin/python2.7 [pynac0.7.14] checking for a version of Python >= '2.1.0'... yes [pynac0.7.14] checking for the distutils Python package... yes [pynac0.7.14] checking for Python include path... I/home/fbissey/sagemath/sage/local/include/python2.7 [pynac0.7.14] checking for Python library path... L/home/fbissey/sagemath/sage/local/lib lpython2.7 [pynac0.7.14] checking for Python sitepackages path... /home/fbissey/sagemath/sage/local/lib/python2.7/sitepackages
As you can see, the first test (AM_PATH_PYTHON
) use sagepython23
properly. But not the second that goes directly for pythonX.Y
. Worse, that's by design of the macro.
AC_PATH_PROG([PYTHON],[python[$PYTHON_VERSION]]) if test z "$PYTHON"; then AC_MSG_ERROR([Cannot find python$PYTHON_VERSION in your system path]) PYTHON_VERSION="" fi
And for the cherry on the top of the cake, I believe PYTHON_VERSION
is set by AM_PATH_PYTHON
. Conclusion AX_PYTHON_DEVEL
doesn't do exotic python name, and you better have a regular python executable in the PATH. Now, I'd like to know more about that setup that has sagepython23
in the PATH but not the matching pythonX.Y
. Did something happen while I wasn't looking?
comment:15 Changed 3 years ago by
Updating AX_PYTHON_DEVEL
would still give the same result. There is probably something smarter to do.
comment:16 followup: 19 Changed 3 years ago by
All the stuff found by AX_PYTHON_DEVEL
could be found by snipping bits of it and using the results from AM_PATH_PYTHON
. This is a substantial rewrite of upstream's configure.ac
that we are looking at. We only need to lift the bits that figure PYTHON_CPPFLAGS
and PYTHON_LDFLAGS
(PYTHON_LIBS
if lifted from the latest version of AX_PYTHON_DEVEL
). The rest is provided by AM_PATH_PYTHON
.
comment:17 Changed 3 years ago by
Replying to fbissey:
Yes for the split. I am surprised that problem shows now in pynac. I would have expected it to happen much earlier. The AX_PYTHON_DEVEL macro is 5 years old  which probably doesn't help.
It shows now because this is a test with system python3 (#27824) instead of building sage's own python3. On macOS, there is /usr/bin/python3
(which is Python 3.7) but no /usr/bin/python3.7
.
comment:18 Changed 3 years ago by
would it work with Homebrew's python3 ? https://formulae.brew.sh/formula/python
Python shipped with MacOS is dodgy, IMHO.
comment:19 Changed 3 years ago by
Replying to fbissey:
All the stuff found by
AX_PYTHON_DEVEL
could be found by snipping bits of it and using the results fromAM_PATH_PYTHON
. This is a substantial rewrite of upstream'sconfigure.ac
that we are looking at. We only need to lift the bits that figurePYTHON_CPPFLAGS
andPYTHON_LDFLAGS
(PYTHON_LIBS
if lifted from the latest version ofAX_PYTHON_DEVEL
). The rest is provided byAM_PATH_PYTHON
.
Yes, this sounds like the correct approach.
comment:20 Changed 3 years ago by
Description:  modified (diff) 

Summary:  Fix build failures of pplpy and pynac on macos with system python3 → Fix build failures of pynac on macos with system python3 
comment:21 Changed 3 years ago by
Replying to dimpase:
This should be probably split into two tickets.
pplpy upstream is https://gitlab.com/videlec/pplpy  also in CC:
pplpy is now #29408
comment:22 Changed 3 years ago by
Some links for AX_PYTHON_DEVEL
:
 current version https://github.com/autoconfarchive/autoconfarchive/blob/master/m4/ax_python_devel.m4
 some patch for it https://0xacab.org/schleuder/rpmgpgme/blob/epel7schleuder/0001fixstupidax_python_devel.patch
 replacement using pythonconfig https://trac.macports.org/attachment/ticket/39223/python.m4
comment:23 Changed 3 years ago by
probably we should try replacement using pythonconfig
 except that the name should not start with AC_
...
comment:25 Changed 3 years ago by
In the same bag, you could be tempted to use pythonX.Y.pc
, AM_PATH_PYTHON
identifies the python version correctly. I eliminated it from my solutions yesterday but that may be viable if it is shipped consistently. If not, the AX_PYTHON_DEVEL
macro just runs python commands to get at sysconfig. It is a fairly valid strategy.
comment:28 Changed 3 years ago by
And on my mac I have python3 but not pythonconfig for it, just python 2.7. So Mac support (without homebrew) needs to probe the python interpreter directly  at the time of writing.
comment:29 followup: 31 Changed 3 years ago by
let us try with Homebrew Python first. One can always add moar insanity later
comment:30 Changed 3 years ago by
That's the path of less resistance but I consider AX_PYTHON_DEVEL
broken (including the latest one) and in need of replacement.
comment:31 Changed 3 years ago by
Replying to dimpase:
let us try with Homebrew Python first. One can always add moar insanity later
Nothing try here. We already know precisely how it fails and what needs fixing: the use of that macro.
comment:32 Changed 3 years ago by
Cc:  Julian Rüth Isuru Fernando added 

comment:33 Changed 2 years ago by
I have a first version of a patch for pynac at https://github.com/pynac/pynac/pull/351
comment:34 Changed 2 years ago by
Branch:  → u/mkoeppe/fix_build_failures_of_pynac_on_macos_with_system_python3 

comment:35 Changed 2 years ago by
Authors:  → Matthias Koeppe 

Commit:  → c97807a2131a7c3d00db3451c18b1bfdfdbe95cd 
Report Upstream:  N/A → Completely fixed; Fix reported upstream 
New commits:
c97807a  build/pkgs/pynac: Use 0.7.26.sage20200328

comment:36 Changed 2 years ago by
Description:  modified (diff) 

Status:  new → needs_review 
comment:37 Changed 2 years ago by
Status:  needs_review → needs_work 

You shouldn't link to the shared python library. If you do, you'll run into https://github.com/pynac/pynac/issues/337
comment:38 Changed 2 years ago by
Help with this is very welcome! I have to work on something else this weekend
comment:39 Changed 2 years ago by
Commit:  c97807a2131a7c3d00db3451c18b1bfdfdbe95cd → 6f2b3362bf0fe885916f7a233c1bb2cac7100186 

Branch pushed to git repo; I updated commit sha1. New commits:
6f2b336  build/pkgs/pynac: Use 0.7.26.sage20200328a

comment:41 Changed 2 years ago by
Status:  needs_work → needs_review 

comment:42 Changed 2 years ago by
comment:43 Changed 2 years ago by
Priority:  major → critical 

This seems to work well according to the tests. Needs review!
comment:44 followup: 45 Changed 2 years ago by
Status:  needs_review → needs_work 

scipy build in macoshomebrewstandard fails with a similar error:
20200329T03:07:22.1134510Z g++ sdk macosx clang bundle undefined dynamic_lookup bundle undefined dynamic_lookup L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/local/lib Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/local/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/opt/readline/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/lib D__ACCELERATE__ I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/opt/readline/include I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/include build/temp.macosx10.14x86_643.7/scipy/interpolate/src/_interpolate.o Lbuild/temp.macosx10.14x86_643.7 o build/lib.macosx10.14x86_643.7/scipy/interpolate/_interpolate.cpython37mdarwin.so 20200329T03:07:22.1135020Z clang: error: unknown argument: 'sdk' 20200329T03:07:22.1135400Z clang: error: no such file or directory: 'macosx' 20200329T03:07:22.1135790Z clang: error: no such file or directory: 'clang' 20200329T03:07:22.1137100Z error: Command "g++ sdk macosx clang bundle undefined dynamic_lookup bundle undefined dynamic_lookup L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/local/lib Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/local/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/opt/readline/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/lib D__ACCELERATE__ I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/opt/readline/include I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localhomebrewmacosstandard/homebrew/include build/temp.macosx10.14x86_643.7/scipy/interpolate/src/_interpolate.o Lbuild/temp.macosx10.14x86_643.7 o build/lib.macosx10.14x86_643.7/scipy/interpolate/_interpolate.cpython37mdarwin.so" failed with exit status 1 20200329T03:07:22.1137680Z Running setup.py install for scipy: finished with status 'error'
comment:45 Changed 2 years ago by
Status:  needs_work → needs_review 

comment:46 Changed 2 years ago by
what do you mean, wrong ticket? I looked at the test results at comment:42 above (https://github.com/mkoeppe/sage/actions/runs/65556636)
comment:47 Changed 2 years ago by
This ticket is about pynac failing with configure: error: Cannot find python3.7 in your system path
.
comment:48 Changed 2 years ago by
Reviewers:  → Dima Pasechnik 

Status:  needs_review → positive_review 
OK, this looks good. Sorry for confusion.
comment:49 Changed 2 years ago by
Status:  positive_review → needs_work 

Thanks for looking into this. This needs more work due to https://github.com/pynac/pynac/pull/351#discussion_r399846249.
comment:50 Changed 2 years ago by
Whether this is good enough for upstream is another question  and one that will not be answered soon. But the fix works for us.
comment:51 Changed 2 years ago by
Does it though? I assume that warning gets triggered in osx system python.
comment:52 Changed 2 years ago by
This is using the version with assert, and it's not failing. See logs above.
comment:53 followup: 54 Changed 2 years ago by
Status:  needs_work → positive_review 

I don't understand how it's going to work, but not going to hold up this ticket.
comment:54 Changed 2 years ago by
Replying to isuruf:
I don't understand how it's going to work
Just in case you'd like another look, here's the log from https://github.com/mkoeppe/sage/actions/runs/66127777, logscommit3fc71b184bd15f5b10e48334eccb73be63dd3033toxlocalhomebrewmacosstandard.zip . Note that this is NOT using the change from #29408.
pynac0.7.26.sage20200328a ==================================================== Setting up build directory for pynac0.7.26.sage20200328a Finished extraction No patch files found in ../patches **************************************************** Host system: Darwin Mac1306.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu6153.81.5~1/RELEASE_X86_64 x86_64 **************************************************** C compiler: x86_64appledarwin13.4.0clang C compiler version: clang version 9.0.1 Target: x86_64appledarwin13.4.0 Thread model: posix InstalledDir: /Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/bin **************************************************** Package 'pynac' is currently not installed No legacy uninstaller found for 'pynac'; nothing to do Starting build... Running build_pynac... Configuring pynac0.7.26.sage20200328a ... checking whether sagepython23 version is >= 2.7... yes checking for sagepython23 version... 3.7 checking for sagepython23 platform... darwin checking for sagepython23 script directory... ${prefix}/lib/python3.7/sitepackages checking for sagepython23 extension module directory... ${exec_prefix}/lib/python3.7/sitepackages checking for Python preprocessor flags... I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/include/python3.7m I/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/include/python3.7m fnostrictaliasing Wsigncompare Wunreachablecode DNDEBUG fwrapv O3 Wall Wstrictprototypes march=core2 mtune=haswell mssse3 ftreevectorize fPIC fPIE fstackprotectorstrong O3 pipe fdebugprefixmap=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}${PKG_VERSION} fdebugprefixmap=/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda=/usr/local/src/condaprefix flto Wl,export_dynamic march=core2 mtune=haswell mssse3 ftreevectorize fPIC fPIE fstackprotectorstrong O3 checking for Python library flags... bundle undefined dynamic_lookup Wl,pie Wl,headerpad_max_install_names Wl,dead_strip_dylibs Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib flto Wl,export_dynamic Wl,pie Wl,headerpad_max_install_names Wl,dead_strip_dylibs Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/local/lib Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/local/lib Wl,rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib L/Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/lib march=core2 mtune=haswell mssse3 ftreevectorize fPIC fPIE fstackprotectorstrong O2 pipe isystem /Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/include D_FORTIFY_SOURCE=2 mmacosxversionmin=10.9 isystem /Users/runner/runners/2.165.2/work/sage/sage/.tox/localcondaforgemacosstandard/conda/include checking build system type... x86_64appledarwin19.3.0
comment:55 Changed 2 years ago by
Fails on cygwin (https://github.com/mkoeppe/sage/runs/548082943):
[pynac0.7.26.sage20200328a] /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac0.7.26.sage20200328a/src/ginac/numeric.cpp:175: undefined reference to `PyErr_Occurred' [pynac0.7.26.sage20200328a] /usr/lib/gcc/x86_64pccygwin/9.3.0/../../../../x86_64pccygwin/bin/ld: .libs/libpynac_lanumeric.o:/cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac0.7.26.sage20200328a/src/ginac/numeric.cpp:502: undefined reference to `PyLong_FromLong' [pynac0.7.26.sage20200328a] /usr/lib/gcc/x86_64pccygwin/9.3.0/../../../../x86_64pccygwin/bin/ld: .libs/libpynac_lanumeric.o: in function `__static_initialization_and_destruction_0': [pynac0.7.26.sage20200328a] /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac0.7.26.sage20200328a/src/ginac/numeric.cpp:503: undefined reference to `PyLong_FromLong' [pynac0.7.26.sage20200328a] /usr/lib/gcc/x86_64pccygwin/9.3.0/../../../../x86_64pccygwin/bin/ld: /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac0.7.26.sage20200328a/src/ginac/numeric.cpp:504: undefined reference to `PyLong_FromLong' [pynac0.7.26.sage20200328a] collect2: error: ld returned 1 exit status [pynac0.7.26.sage20200328a] make[6]: *** [Makefile:558: libpynac.la] Error 1
comment:56 Changed 2 years ago by
Cc:  Erik Bray added 

comment:57 Changed 2 years ago by
Status:  positive_review → needs_work 

comment:58 Changed 2 years ago by
Commit:  6f2b3362bf0fe885916f7a233c1bb2cac7100186 → db5074a5487edaa6ce153d5a7812387539fc8c7a 

Branch pushed to git repo; I updated commit sha1. New commits:
db5074a  Use pynac0.7.26.sage20200331a

comment:59 Changed 2 years ago by
Status:  needs_work → needs_review 

comment:60 Changed 2 years ago by
Status:  needs_review → needs_work 

comment:61 Changed 2 years ago by
Commit:  db5074a5487edaa6ce153d5a7812387539fc8c7a → deb717fb4c53b2851a04fff610f98ca0ff80f84a 

comment:64 Changed 2 years ago by
Commit:  deb717fb4c53b2851a04fff610f98ca0ff80f84a → 7344e2df8bebecdab19924a14ff4dbe51cc514f9 

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
7344e2d  Use temporary upstream version pynac0.7.26.sage20200403

comment:66 Changed 2 years ago by
Correct builds can be seen at https://github.com/mkoeppe/sage/actions/runs/74117913
comment:67 Changed 2 years ago by
It's good on OS X, built with various different Pythons (homebrew, system, Sage).
comment:71 Changed 2 years ago by
Priority:  critical → blocker 

Changed 2 years ago by
Attachment:  pynac0.7.26.sage20200403.log added 

pynac did not download on Mac OS 10.15.3
comment:72 Changed 2 years ago by
I apologize if this is noise (I may have messed up my installation somehow), but I thought I should report that I had trouble building pynac in 9.1rc0 on Mac OS 10.15.3, even with this ticket:
Attempting to download from https://github.com/mkoeppe/pynac/releases/download/pynac0.7.26.sage20200403/pynac0.7.26.sage20200403.tar.bz2 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] ERROR [transferrun:135]: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056) ************************************************************************
I merged #29408 and this ticket, and ran make build
, then realized that the description of this ticket has a different make command, so I tried that, too. But pynac did not download. I am attaching the pynac0.7.26.sage20200403.log
log file from the more complicated build command, in case it is of use.
The build went smoothly after I manually downloaded pynac and put it in the upstream directory, so I want to say thanks for these patches! I never would have figured out how to fix the build errors on my own.
comment:73 Changed 2 years ago by
this might be due to (system) python, more precisely its urllib module, being unable to provide correct certs...
does installing python 3.7 from python.org and also making sure it installs certs (there is a 2nd step in installation, iirc) fixes this?
comment:74 Changed 2 years ago by
Yes, that solved the problem. After installing python and certifi, pynac downloaded from mkoeppe's directory (and the build succeeded) when I used make SAGE_SPKG="sagespkg o" pynacclean pynac
. Thanks!
comment:75 Changed 2 years ago by
Branch:  u/mkoeppe/fix_build_failures_of_pynac_on_macos_with_system_python3 → 7344e2df8bebecdab19924a14ff4dbe51cc514f9 

Resolution:  → fixed 
Status:  positive_review → closed 
comment:76 Changed 2 years ago by
Commit:  7344e2df8bebecdab19924a14ff4dbe51cc514f9 

Follow up: #29872
pynac's python discovery should be fixed, this looks completely broken