Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#59410 closed defect (fixed)

pypy @7.2.0: The _hashlib module is not available

Reported by: rbubley Owned by: danchr (Dan Villiom Podlaski Christiansen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: pypy

Description

My experience (and apparently on the buildbot), is that on MacOS 10.13, the destroot stage fails:

Error: Failed to destroot pypy: command execution failed

Looking at the log files, the key error seems to be

:info:destroot DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.13" but "10.14" during configure

Change History (8)

comment:1 Changed 5 years ago by jmroot (Joshua Root)

Owner: set to danchr
Status: newassigned

comment:2 Changed 5 years ago by jmroot (Joshua Root)

Example log: https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/102963/steps/install-port/logs/stdio

The actual problem seems to be that it's failing to find all the library dependencies (openssl, ncurses, etc) in the build phase, and the deployment target error is just a result of it retrying in the destroot phase for some reason.

comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: pypy @7.2.0: Doesn't install on MacOS < 10.14pypy @7.2.0: The _hashlib module is not available

I am able to reproduce this problem when building on my High Sierra machine with trace mode.

I don't see anything in the log mentioning a problem with ncurses, but I do see this at the end of the build phase:

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/lib-python/2.7/hashlib.py:146: RuntimeWarning: The _hashlib module is not available, falling back to a much slower implementation (No module named _pypy_openssl)
  RuntimeWarning)
* _ssl_build.py
fetching archive https://www.openssl.org/source/openssl-1.1.1c.tar.gz
Traceback (most recent call last):
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/pypy/tool/build_cffi_imports.py", line 227, in <module>
    rebuild=args.rebuild)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/pypy/tool/build_cffi_imports.py", line 157, in create_cffi_import_libraries
    status, stdout, stderr = _build_dependency(key)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/pypy/tool/build_cffi_imports.py", line 91, in _build_dependency
    urlretrieve(url, archive)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/lib-python/2.7/urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/lib-python/2.7/urllib.py", line 245, in retrieve
    fp = self.open(url, data)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/lib-python/2.7/urllib.py", line 210, in open
    return self.open_unknown(fullurl, data)
  File "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_pypy/pypy/work/pypy2.7-v7.2.0-src/lib-python/2.7/urllib.py", line 222, in open_unknown
    raise IOError, ('url error', 'unknown url type', type)
IOError: [Errno url error] unknown url type: 'https'

So it failed to download openssl, but we wouldn't want it to do that anyway (ports should only download files during the fetch phase), and it's only doing that because the _hashlib module is not available. Looking at the contents of python27 I see that it contains _hashlib, but looking at the contents of pypy-bootstrap I see that it does not. I don't know how to give pypy-bootstrap a _hashlib module.

This port uses pypy-bootstrap to build on Darwin x86_64 systems and python27 to build on other systems. Unless a previous version of pypy is installed and trace mode is not being used, in which case it uses that.

This is kind of the problem with ports that do different things depending on what's already on the user's system. Presumably the maintainer didn't notice this because he had a previous version installed and wasn't using trace mode. It would be more consistent to always build the same way. That would ensure there are no surprises since all users will build the port the same way that the maintainer built the port.

Last edited 4 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:4 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign added

Dan, what do you want to do about this?

comment:5 in reply to:  4 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)

Replying to ryandesign:

Dan, what do you want to do about this?

I need to update the port anyway, so I'll try harder to suppress the embedding logic, and remove the trace mode hackery. (I always use trace mode myself.)

comment:6 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)

In 460f1b130da2390b624240a135f572aca13de9e0/macports-ports (master):

pypy: update to 7.3.0

  • move tkinter support to subport to simplify upgrades
  • don't try to use preinstalled binary depending on trace mode

Re: #59410

comment:7 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)

Resolution: fixed
Status: assignedclosed

I believe I fixed this some time ago.

comment:8 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)

In 460f1b130da2390b624240a135f572aca13de9e0/macports-ports (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):

pypy: update to 7.3.0

  • move tkinter support to subport to simplify upgrades
  • don't try to use preinstalled binary depending on trace mode

Re: #59410

Note: See TracTickets for help on using tickets.