<div>Hi,<br></div><div><br></div><div>It's because it either uses<br></div><div><br></div><div>arch<br></div><div><br></div><div>or <br></div><div><br></div><div>uname -m<br></div><div><br></div><div>Both of which *now* return<br></div><div><br></div><div>gresil:~$ uname -m<br></div><div>aarch64<br></div><div>gresil:~$ arch<br></div><div>aarch64<br></div><div>gresil:~$<br></div><div><br></div><div>To me this seems broken.  But that is what it does now.<br></div><div><br></div><div>It is a 64 bit kernel now.  But 32 bit userland.<br></div><div><br></div><div>cheers<br></div><div><br></div><div>bruce</div><div ><br></div><div class="ik_mail_quote answerContentMessage" ><div>On 2023-03-31T14:43:06.000+02:00, Tobias Pape <Das.Linux@gmx.de> wrote:</div><blockquote class="ws-ng-quote"><pre style="white-space: normal;">Thanks a  bunch.<br/>seeing that, I'm slightly puzzled how configure ended up with aarch64.<br/>But maybe I've some time ahead :)<br/><br/>Best regards<br/>       -Tobias<br/><br/><blockquote class="ws-ng-quote">  On 31. Mar 2023, at 14:08, Bruce O'Neel <<a target="_blank"  class="defaultMailLink" href="mailto:bruce.oneel@pckswarms.ch">bruce.oneel@pckswarms.ch</a>> wrote:<br/> <br/> HI,<br/> <br/> Here you go:<br/> <br/> DEB_BUILD_ARCH=armhf<br/> DEB_BUILD_ARCH_ABI=eabihf<br/> DEB_BUILD_ARCH_BITS=32<br/> DEB_BUILD_ARCH_CPU=arm<br/> DEB_BUILD_ARCH_ENDIAN=little<br/> DEB_BUILD_ARCH_LIBC=gnu<br/> DEB_BUILD_ARCH_OS=linux<br/> DEB_BUILD_GNU_CPU=arm<br/> DEB_BUILD_GNU_SYSTEM=linux-gnueabihf<br/> DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf<br/> DEB_BUILD_MULTIARCH=arm-linux-gnueabihf<br/> DEB_HOST_ARCH=armhf<br/> DEB_HOST_ARCH_ABI=eabihf<br/> DEB_HOST_ARCH_BITS=32<br/> DEB_HOST_ARCH_CPU=arm<br/> DEB_HOST_ARCH_ENDIAN=little<br/> DEB_HOST_ARCH_LIBC=gnu<br/> DEB_HOST_ARCH_OS=linux<br/> DEB_HOST_GNU_CPU=arm<br/> DEB_HOST_GNU_SYSTEM=linux-gnueabihf<br/> DEB_HOST_GNU_TYPE=arm-linux-gnueabihf<br/> DEB_HOST_MULTIARCH=arm-linux-gnueabihf<br/> DEB_TARGET_ARCH=armhf<br/> DEB_TARGET_ARCH_ABI=eabihf<br/> DEB_TARGET_ARCH_BITS=32<br/> DEB_TARGET_ARCH_CPU=arm<br/> DEB_TARGET_ARCH_ENDIAN=little<br/> DEB_TARGET_ARCH_LIBC=gnu<br/> DEB_TARGET_ARCH_OS=linux<br/> DEB_TARGET_GNU_CPU=arm<br/> DEB_TARGET_GNU_SYSTEM=linux-gnueabihf<br/> DEB_TARGET_GNU_TYPE=arm-linux-gnueabihf<br/> DEB_TARGET_MULTIARCH=arm-linux-gnueabihf<br/> <br/> <br/> cheers<br/> bruce<br/> <br/> On 2023-03-31T13:08:28.000+02:00, Tobias Pape <<a target="_blank"  class="defaultMailLink" href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br/> Hey Bruce<br/> <br/> <br/> On 31. Mar 2023, at 12:03, Bruce O'Neel <<a target="_blank"  class="defaultMailLink" href="mailto:bruce.oneel@pckswarms.ch">bruce.oneel@pckswarms.ch</a>> wrote:<br/> <br/> Hi,<br/> <br/> That's a good idea, but let's wait just a touch. I suspect that we're not the only ones running into this.<br/> <br/> The only place where we would need this is around line 18582 of <br/> <br/> opensmalltalk-vm/platforms/unix/config/configure<br/> <br/> aarch64)<br/> # Check whether --enable-fast-bitblt was given.<br/> if test "${enable_fast_bitblt+set}" = set; then :<br/> enableval=$enable_fast_bitblt; if test "x$enableval" = "xyes" ; then<br/> bitblt_objs="BitBltPlugin.o BitBltArm64.o BitBltDispatch.o BitBltGeneric.o"<br/> bitblt_flags="-DENABLE_FAST_BLT"<br/> fi<br/> <br/> fi<br/> <br/> This seems to be the only place where we use the architecture and we have not overridden it.<br/> <br/> Also I think we should have a bigger discussion about do we continue with 32 bit OSes and/or 32 bit builds? But I'll make that a separate email exchange.<br/> <br/> <br/> since its a raspbian, can you get me the output of<br/> <br/> $ dpkg-architecture<br/> <br/> ? I think we could well work with that…<br/> <br/> Best regards<br/> -Tobias<br/> <br/> cheers<br/> <br/> bruce<br/> <br/> <br/> On 2023-03-30T23:22:16.000+02:00, Eliot Miranda <<a target="_blank"  class="defaultMailLink" href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br/> Hi Bruce,<br/> <br/> maybe we should introduce a helper C file, wordsize.c or some such. It could be as simple as<br/> <br/> #include <stdio.h><br/> int main() { printf("%d\n", sizeof(void *)); return 0; }<br/> <br/> we would then compile that first and use its output to determine what to do next. More reliable than uname? What do you think?<br/> <br/> <br/> On Thu, Mar 30, 2023 at 11:23 AM Bruce O'Neel <<a target="_blank"  class="defaultMailLink" href="mailto:bruce.oneel@pckswarms.ch">bruce.oneel@pckswarms.ch</a>> wrote:<br/> Hi all,<br/> <br/> First, this is not our problem :-). But it affects us.<br/> <br/> I have kept a 32 bit Pi OS around even though the rest of my ARM systems are 64 bit.<br/> <br/> Until today Squeak built fine. The last build I did was 901401c from the 28th but tonight it started failing on Pi OS 32 bit with:<br/> <br/> tmp/opensmalltalk-vm/platforms/Cross/plugins/BitBltPlugin/BitBltArm64.c:261:9: error: invalid 'asm': invalid operand for code 'w'<br/> <br/> which is bizarre. Why would it start building the BitBltArm64.c plugin? It's ARM32 (armv7l to be exact). <br/> <br/> And the is no way that the two commits since the last successful build could have changed this. And what do you know, that commit fails as well now.<br/> <br/> But there is the problem. uname -m returned armv7l. Yesterday <br/> <br/> But today it does not return armv7l. Today uname -m and arch both return aarch64.<br/> <br/> Which is technically at some level correct. This system IS a PI/400 so therefore it is an ARM64, but with a 32 bit OS installed.<br/> <br/> I think the change is this package:<br/> <br/> libc-bin:armhf 2.31-13+rpt2+rpi1+deb11u5<br/> <br/> We'll see if Debian or Raspberry PI fixes this in the next few days.<br/> <br/> cheers<br/> <br/> bruce</pre></blockquote></div>