Hi,

It's because it either uses

arch

or 

uname -m

Both of which *now* return

gresil:~$ uname -m

aarch64

gresil:~$ arch

aarch64

gresil:~$

To me this seems broken.  But that is what it does now.

It is a 64 bit kernel now.  But 32 bit userland.

cheers

bruce

On 2023-03-31T14:43:06.000+02:00, Tobias Pape <Das.Linux at gmx.de>
wrote:

Thanks a  bunch.
seeing that, I'm slightly puzzled how configure ended up with aarch64.
But maybe I've some time ahead :)

Best regards
    -Tobias

  On 31. Mar 2023, at 14:08, Bruce O'Neel <bruce.oneel at pckswarms.ch> wrote:
 
 HI,
 
 Here you go:
 
 DEB_BUILD_ARCH=armhf
 DEB_BUILD_ARCH_ABI=eabihf
 DEB_BUILD_ARCH_BITS=32
 DEB_BUILD_ARCH_CPU=arm
 DEB_BUILD_ARCH_ENDIAN=little
 DEB_BUILD_ARCH_LIBC=gnu
 DEB_BUILD_ARCH_OS=linux
 DEB_BUILD_GNU_CPU=arm
 DEB_BUILD_GNU_SYSTEM=linux-gnueabihf
 DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf
 DEB_BUILD_MULTIARCH=arm-linux-gnueabihf
 DEB_HOST_ARCH=armhf
 DEB_HOST_ARCH_ABI=eabihf
 DEB_HOST_ARCH_BITS=32
 DEB_HOST_ARCH_CPU=arm
 DEB_HOST_ARCH_ENDIAN=little
 DEB_HOST_ARCH_LIBC=gnu
 DEB_HOST_ARCH_OS=linux
 DEB_HOST_GNU_CPU=arm
 DEB_HOST_GNU_SYSTEM=linux-gnueabihf
 DEB_HOST_GNU_TYPE=arm-linux-gnueabihf
 DEB_HOST_MULTIARCH=arm-linux-gnueabihf
 DEB_TARGET_ARCH=armhf
 DEB_TARGET_ARCH_ABI=eabihf
 DEB_TARGET_ARCH_BITS=32
 DEB_TARGET_ARCH_CPU=arm
 DEB_TARGET_ARCH_ENDIAN=little
 DEB_TARGET_ARCH_LIBC=gnu
 DEB_TARGET_ARCH_OS=linux
 DEB_TARGET_GNU_CPU=arm
 DEB_TARGET_GNU_SYSTEM=linux-gnueabihf
 DEB_TARGET_GNU_TYPE=arm-linux-gnueabihf
 DEB_TARGET_MULTIARCH=arm-linux-gnueabihf
 
 
 cheers
 bruce
 
 On 2023-03-31T13:08:28.000+02:00, Tobias Pape <Das.Linux at gmx.de> wrote:
 Hey Bruce
 
 
 On 31. Mar 2023, at 12:03, Bruce O'Neel <bruce.oneel at pckswarms.ch> wrote:
 
 Hi,
 
 That's a good idea, but let's wait just a touch. I suspect that we're not the only ones running into this.
 
 The only place where we would need this is around line 18582 of 
 
 opensmalltalk-vm/platforms/unix/config/configure
 
 aarch64)
 # Check whether --enable-fast-bitblt was given.
 if test "${enable_fast_bitblt+set}" = set; then :
 enableval=$enable_fast_bitblt; if test "x$enableval" = "xyes" ; then
 bitblt_objs="BitBltPlugin.o BitBltArm64.o BitBltDispatch.o BitBltGeneric.o"
 bitblt_flags="-DENABLE_FAST_BLT"
 fi
 
 fi
 
 This seems to be the only place where we use the architecture and we have not overridden it.
 
 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.
 
 
 since its a raspbian, can you get me the output of
 
 $ dpkg-architecture
 
 ? I think we could well work with that…
 
 Best regards
 -Tobias
 
 cheers
 
 bruce
 
 
 On 2023-03-30T23:22:16.000+02:00, Eliot Miranda <eliot.miranda at gmail.com> wrote:
 Hi Bruce,
 
 maybe we should introduce a helper C file, wordsize.c or some such. It could be as simple as
 
 #include <stdio.h>
 int main() { printf("%d\n", sizeof(void *)); return 0; }
 
 we would then compile that first and use its output to determine what to do next. More reliable than uname? What do you think?
 
 
 On Thu, Mar 30, 2023 at 11:23 AM Bruce O'Neel <bruce.oneel at pckswarms.ch> wrote:
 Hi all,
 
 First, this is not our problem :-). But it affects us.
 
 I have kept a 32 bit Pi OS around even though the rest of my ARM systems are 64 bit.
 
 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:
 
 tmp/opensmalltalk-vm/platforms/Cross/plugins/BitBltPlugin/BitBltArm64.c:261:9: error: invalid 'asm': invalid operand for code 'w'
 
 which is bizarre. Why would it start building the BitBltArm64.c plugin? It's ARM32 (armv7l to be exact). 
 
 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.
 
 But there is the problem. uname -m returned armv7l. Yesterday 
 
 But today it does not return armv7l. Today uname -m and arch both return aarch64.
 
 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.
 
 I think the change is this package:
 
 libc-bin:armhf 2.31-13+rpt2+rpi1+deb11u5
 
 We'll see if Debian or Raspberry PI fixes this in the next few days.
 
 cheers
 
 bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230331/34be4753/attachment.html>