cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<mattip>
it seems the test_embedded failures on windows are not a test artifact
<mattip>
something is off with the _cffi_start_python code on windows that causes a crash
<mattip>
adding printf in _embedding.h, it seems pypy_carefully_make_gil crashes on pypy2.7, win32
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<mattip>
I threw a bunch of print statements into _cffi_backend/embedding.py and am translating locally
<mattip>
if anyone has a better idea for debugging that would be great
otisolsen70 has joined #pypy
<mattip>
(the failing extra_tests/cffi/embedding tests are what got me started)
lritter has joined #pypy
<the_drow[m]>
Hi everyone!
<the_drow[m]>
What do you think about Pyston's new approach using DynASM?
<antocuni>
the_drow[m]: link?
<the_drow[m]>
arigato: I wonder if we could have a multi-phase JIT where we have our tracing JIT for hot spots and something like DynASM which compiles code very quickly.
<matt4d617474>
hiya; is there a known workaround for the error condition described by: undefined symbol for SSL_CTX_set_min_proto_version during the build_cffi_imports phase of the pypy build?
<matt4d617474>
i have the openssl-devel package installed
<matt4d617474>
this is on a rhel7 box, fwiw
<tumbleweed>
that symbol was added in openssl 1.1.0
<tumbleweed>
I can't see anything in pypy using it directly
<tumbleweed>
can you pase the full traceback?
<matt4d617474>
so the rhel7 openssl version is 1.0.2k
<matt4d617474>
yeah, do you have a preferred pastebin in this channel?
<tumbleweed>
ah, I see cryptography declares 1.1.0 as being the oldest version it supported
<matt4d617474>
well, shoot
<matt4d617474>
maybe can't get there from here sort of deal
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
<tumbleweed>
but that's latest cryptography
<tumbleweed>
and a releatively recent change. pypy hasn't adopted that yet
<tumbleweed>
I'm guessing lib_pypy/_pypy_openssl.pypy37-pp73-x86_64-linux-gnu.so is the shipped version
<tumbleweed>
just delete it and re-run the build?
<matt4d617474>
sure, i'll give that a go 1s
<matt4d617474>
ok, so that .so isn't part of the source distribution
<matt4d617474>
think it was created as part of the earlier build phases
<matt4d617474>
but i may be misunderstanding what you mean by "shipped version"?
<tumbleweed>
the prebuilt version you downloaded from pypy.org includes built cffi modules, IIRC
<matt4d617474>
i'm trying to build from sources
<matt4d617474>
looks like that _ssl_build.py is responsible for creating that .so file
<tumbleweed>
yes
<tumbleweed>
and it shouldn't be referring to symbols that aren't available
<tumbleweed>
so, either you have a mess of multiple openssls that is confusing something
<tumbleweed>
or that was built against a newer openssl
<tumbleweed>
delete it and re-run the build, and we'll get a better idea of what's going on
<matt4d617474>
i'd be prone to suggest the same in your shoes... but there is only one ssl in this space (building in a subcontainer, ldconfig -p shows the expected 1.0.2k system libraries and nothing more)
<matt4d617474>
have done that and got the same results sadly
<matt4d617474>
thank you for your time and help, btw!
<mattip>
maybe there is a mismatch with the libraries and the headers?
<matt4d617474>
possible? the system itself has consistent/same libs and headers for openssl... i'm digging in that _cffi_ssl space now to see how it's working
<mattip>
nope. It is part of python3.7. Does that support older ssl?
<matt4d617474>
seemingly yes (at least my python3.8 package supports ssl insofar as an "import ssl" works and obviously is backed by the same v1.0.2k)
<mattip>
ok, so it is a bug. Those defines should have a guard for older openssl
<matt4d617474>
bug where? apologies for not following along as well ... in py37 sources? in pypy integration of py37?
<matt4d617474>
should i submit a bug report? i'm happy to do some legwork
<mattip>
in the py3.7 sources. In commit 521c745626d2 I added them unconditionally to lib_pypy/_cffi_ssl/_cffi_src/openssl/ssl.py
<mattip>
cpython has a C implementation of _ssl
<mattip>
pypy uses cryptography and a cffi interface layer
<matt4d617474>
got it
<mattip>
to provide _ssl
<mattip>
python is proposing to drop support for pre-1.1.1, I guess I jumped the gun
<tumbleweed>
ah, I was looking at 3.6 that didn't have chat change
<mattip>
matt4d617474: are you sure you want to build your own PyPy? The ones at https://www.pypy.org/download.html should work on rhel7
<mattip>
and include openssl 1.1.1
<matt4d617474>
kinda torn, our team's policy (and i'm sympathetic) is we manage all software from sources to build across the entire estate for better control, patchability
<matt4d617474>
but we're kinda POC'ing pypy anyway at this stage so maybe just a binary would be appropriate at this stage
<matt4d617474>
though i feel i'm fairly close at this stage of the build too
<matt4d617474>
and happy to work out bugs
<matt4d617474>
etc.
<mattip>
ok, so add openblas to the mix. If you use our packaging script you can tell it to download and build openssl
<tumbleweed>
makes sense if you're stuck on rhel7 :)