On Wed, Nov 30, 2022 at 8:26 PM Jeffrey Walton <noloa...@gmail.com> wrote: > > On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS) <g...@debian.org> > wrote: > > ... > > You may locally hack the build of boost1.74 not to require Python > > (and drop its related binary packages). Of course, best would be to > > port python-greenlet to sh4 or just fix its build - can you give a > > helping hand to its upstream? > > At least this is what I see without access to any sh4 machine. As we > > know each other, I may check it for you if I can access that machine. > > But I think you are much more skilled in these things. > > Yes, sure. Let me take a look at python-greenlet on SH4.
Ok, so I had a look at this last night. I don't think I am going to be able to help with improving Greenlet. For Greenlet, I think the best course of action is to ping the Greenlet developers and ask them for help with SH4. The #error is triggered because there's no switch_sh4_linux.h in [1]. The file provides a function called slp_switch(), and it is inline ASM. Based on other arch files, it looks like the function does some sort of manual switching on app-managed lightweight threads. So the function uses inline ASM to save/restore registers and move the stack pointer around (if I am parsing things correctly). Unfortunately, I think that's a bit outside my comfort zone. I don't know Greenlet, and I don't know SH4 ASM. For completeness, here is the SH4 software manual: [2]. If the Greenlet developers decline to port to SH4, then I think the next step is to remove the Greenlet dependency on SH4. Maybe there's a configure option in GDB, Boost or Python that can ultimately sidestep the dependency on SH4. I think the first team to engage is the GDB team. They may have a suggestion to shed the Boost dependency. [1] https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform [2] https://www.renesas.com/us/en/document/mas/sh-4-software-manual
