I'm working on a Debian Chroot for SH4 machine. I am trying to install GDB. The GDB installation fails: # apt install gdb Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libboost-regex1.74.0 : Depends: libicu71 (>= 71.1-1~) but it is not installable E: Unable to correct problems, you have held broken packages. The rub is, SH4 is not listed at https://packages.debian.org/sid/libicu71 . The package page also shows version 71.1-3, not 71.1-1. I'm not really sure how to proceed.
Hi Jeffrey, [...] Unfortunately this is correct. The sh4 architecture is only an unofficial port of Debian, a secondary architecture. It seems it can't keep up with package changes. Architectures transitioned to ICU 72.1 (version is 72.1-3 to be exact) and that's also built for sh4 [1]. Reason why boost1.74 can't pick that up seems to be numpy; build status [2] shows it needs build dependency on python3-numpy (>= 1:1.21.5-2) and libicu-dev (>= 72). The latter is OK, but stuck on the former [3]. To cut it short, digging down on the mentioned page through python3-matplotlib I see the culprit build dependency is python-greenlet [4] which fails to build on sh4. It seems it was never built there as the error is [5]: src/greenlet/greenlet.c:376:6: error: #error "greenlet needs to be ported to this platform, or taught how to detect your compiler properly." That's because ICU was transitioned to version 72.1 as noted above which also happened and available on sh4 [6]. 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. Regards, Laszlo/GCS [1] https://buildd.debian.org/status/package.php?p=icu [2] https://buildd.debian.org/status/package.php?p=boost1.74 [3] https://buildd.debian.org/status/package.php?p=numpy [4] https://buildd.debian.org/status/package.php?p=python-greenlet [5] https://buildd.debian.org/status/fetch.php?pkg=python-greenlet&arch=sh4&ver=1.1.3-1&stamp=1668258039&raw=0 [6] https://packages.debian.org/sid/libicu72
Yes, sure. Let me take a look at python-greenlet on SH4. I would have done that already, but I could not figure out which package was the problem. Sorry about that! One word of caution... python-greenlet is described as "greenlets are lightweight coroutines for in-process sequential concurrent programming." I know Git has a problem with threads on SH4.[1] So the problem may be a little deeper than a library port. It may be down in libc or the kernel. Put another way, it may be beyond my skill level. [1] https://lore.kernel.org/git/CAH8yC8niurChnXPrZSeBa7g1z5AF3PqYdf1X0Rm03rDanec6Gw@mail.gmail.com/ Jeff
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
Ok, so it looks like the Greenlet developers have an open bug report at [1]. It was opened Apr 19, 2020. I'm guessing the Greenlet developers are not going to provide the support given they've had over 2 years to do so. I think that leaves contacting the GDB folks to see if there's a way to sidestep Boost dependency. [1] https://github.com/python-greenlet/greenlet/issues/166
Considering the needed porting work is only a few lines: https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform sh4 porters might be able to help here.
icu or python-greenlet? The former has been built on sh4: Adrian
Looking at the rest of the bug report The reason why boost1.74 is not up to date is this bug: The reason why gdb is missing is this bug report: See also: There is no known issue with icu on sh4. Adrian
I note you can run a debian root filesystem under qemu-system-sh4 with a large swap file on your media image. It's not great (the board only has 64 megs emulated ram so the swap file gets a bit hammered, although the host disk cache covers for it), but it works better than application emulation doing dodgy things with system calls? How does one do an 'entirely from source' debootstrap, anyway? (If I wanted to reproduce your current sh4 build on my system, where would I start?) Rob
For SH-4 I use a Debian Chroot and follow https://cryptopp.com/wiki/Debian_Chroot#SH-4 . Start with Debian Unstable/Sid. Then add the following packages: # apt install qemu qemu-user-static binfmt-support debootstrap debian-archive-keyring debian-ports-archive-keyring And then setup the SH-4 guest: # qemu-debootstrap --arch=sh4 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg \ --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports Finally, enter the SH-4 guest with: # chroot debian-sh4 Jeff
... $ sudo qemu-debootstrap --arch=sh4 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports I: Running command: debootstrap --arch sh4 --foreign --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports I: Retrieving InRelease I: Checking Release signature E: Release signed by unknown key (key id E852514F5DF312F6) The specified keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg may be incorrect or out of date. You can find the latest Debian release key at https://ftp-master.debian.org/keys.html Nope, doesn't work from devuan beowulf. Oh well. Thanks, off to other things... Rob