<vstinner>
mattip: maybe. but someone has to investigate, my team doesn't have the bandwidth to investigate the issue right now
<mattip>
ok, thanks for reporting
<vstinner>
mattip: GCC 12 is already in Fedora 36 which is also under devlopment, but the GCC 12 behavior is unlikely to change. if it's a compiler bug and nobody reports it, it will be in GCC 12 final :-)
mgorny has joined #pypy
<vstinner>
mattip: i found a GCC 12 bug related to HUGE_VAL*0 used by CPython for its Py_NAN constant ;-)
<vstinner>
my question stays: what should be done to make progress on this build error?
<cfbolz>
vstinner: what's the easiest way for me to locally get an environment to reproduce this?
<vstinner>
cfbolz: get a VM running Fedora 36 or Fedora Rawhide. i'm already running Fedora, so I use the mock command which creates a Fedora container, it's cheaper
<vstinner>
"easiest" depends on your OS
<cfbolz>
vstinner: I'm on ubuntu
<vstinner>
cfbolz: hum. i don't know well how PyPy is built for 32-bit
epony has quit [Read error: Connection reset by peer]
<cfbolz>
vstinner: I don't either, honestly :-(
<cfbolz>
it needs a 32bit environment for that
<vstinner>
cfbolz: on my side, i need to investigate a CPython issue with GCC 12 on ppc64le
<cfbolz>
we can't cross-compile
<vstinner>
cfbolz: sorry, my colleague who knows these stuff is busy, i may come back to you later this week
<vstinner>
i asked on the fedora what is the easiest option to reproduce the issue
<vstinner>
on x86-64, you can install 32-bit libc (binary, header file) and gcc -m32 works well to build for 32-bit. i use that time to time to debug 32-bit issue on CPython :-)
<cfbolz>
vstinner: right, but you need a 32bit python to build pypy then too
<mattip>
we build it in a 32-bit docker, running `linux32 <cmd>`
<tumbleweed>
pypy's amd64 build is portable (shared libs are bundled), but the other archs aren't
<glyph>
tumbleweed: does e.g. debian just have their own, separate pypy build process then? the issue here is that they're trying to use upstream binaries on unsupported ("not centos") distributions?
<tumbleweed>
glyph: yes, we build from source. The pypy docker image is presumably using the pre-built tarballs from pypy.org's downloads
greedom has joined #pypy
tazle has quit [Ping timeout: 256 seconds]
nanonyme has quit [Ping timeout: 256 seconds]
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
tazle has joined #pypy
<mattip>
glyph: thanks, I commented on the issue.
<glyph>
mattip: Thanks. Illuminating!
<mattip>
tumbleweed: does debian provide a pkg-config file pypy3.pc as part of the build?
<mattip>
this came up as part of trying to get meson to support pypy
<tumbleweed>
mattip: yeah, so the embedding use-case isn't there. They can also be used by external build systems building C extensions, there's value for having it there
<mattip>
that seems reasonable, but I don't want to make you do more work
<tumbleweed>
nah, .pc files are trivial
<mattip>
cool, thanks
<mattip>
you can skip 7.3.8, I will be releasing 7.3.9
<mattip>
probably with no release candidates, since there are no big changes
<tumbleweed>
+1
<tumbleweed>
I wonder if there's an embargoed security issue in the wings, behind that joint release
<mattip>
hmm, so maybe it would be prudent to wait till they release first?
Atque has quit [Quit: ...]
<tumbleweed>
I don't know if there are usually announcements like that