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
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@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
On 2023-03-30, at 2:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
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.
I see in the archive (http://archive.raspberrypi.org/debian/dists/bullseye/) that there was a load of file updated early today so if you updated very recently that might catch it. I don't see anything mentioned on the forum but I'll post and see if anyone replies.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
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.
cheers
bruce
On 2023-03-30T23:22:16.000+02:00, Eliot Miranda eliot.miranda@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@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
-- _,,,^..^,,,_ best, Eliot
Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
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@gmx.de wrote:
Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
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@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
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@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@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@gmx.de wrote: Hey Bruce On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
I see a number of people have noticed this on the Pi forums - https://forums.raspberrypi.com/viewtopic.php?t=349291
Looks like the latest downloadable images have been changed to use the 64bit kernel but allow a 32bit userland.
A suggestion is to use `dpkg --print-architecture`
On 2023-03-31, at 5:48 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
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@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@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
And...
"There has been a change to the default kernel loaded on 64-bit capable Pis. The 64-bit (aarch64) kernel is now the default for those systems.
You can use another method to detect the software architecture (dpkg --print-architecture is one method).
Or you can force the 32-bit (armv7l or others) kernel to be used by putting arm_64bit=0 in /boot/config.txt"
On 2023-03-31, at 10:50 AM, tim Rowledge tim@rowledge.org wrote:
I see a number of people have noticed this on the Pi forums - https://forums.raspberrypi.com/viewtopic.php?t=349291
Looks like the latest downloadable images have been changed to use the 64bit kernel but allow a 32bit userland.
A suggestion is to use `dpkg --print-architecture`
On 2023-03-31, at 5:48 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
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@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@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Original Sin is hard to find, but the digitally enhanced version is readily available.
Hi Bruche
one more thing,
could you go to platforms/unix/config/
and download now config.guess/sub?
curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
And give me the output of ./config.guess and ./config.sub $(./config.guess) ?
Best regards -Tobias
On 31. Mar 2023, at 14:08, Bruce O'Neel bruce.oneel@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
Thanks. I’m not at home so no ARM32 systems this instant. Maybe next week early.
Sorry
Cheers
Bruce
On 2023-04-04T13:53:22.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi Bruche
one more thing,
could you go to platforms/unix/config/
and download now config.guess/sub?
curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
And give me the output of ./config.guess and ./config.sub $(./config.guess) ?
Best regards -Tobias
On 31. Mar 2023, at 14:08, Bruce O'Neel bruce.oneel@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@gmx.de wrote: Hey Bruce On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
no problem :)
On 5. Apr 2023, at 14:52, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Thanks. I’m not at home so no ARM32 systems this instant. Maybe next week early.
Sorry
Cheers
Bruce On 2023-04-04T13:53:22.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruche
one more thing,
could you go to platforms/unix/config/
and download now config.guess/sub?
curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
And give me the output of ./config.guess and ./config.sub $(./config.guess) ?
Best regards -Tobias
On 31. Mar 2023, at 14:08, Bruce O'Neel bruce.oneel@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
Hi,
Here you go:
~/tmp/opensmalltalk-vm/platforms/unix/config$ curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 49938 0 49938 0 0 57731 0 --:--:-- --:--:-- --:--:-- 57665
~/tmp/opensmalltalk-vm/platforms/unix/config$ curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 35818 0 35818 0 0 37349 0 --:--:-- --:--:-- --:--:-- 37349
~/tmp/opensmalltalk-vm/platforms/unix/config$ ./config.guess
aarch64-unknown-linux-gnu
:~/tmp/opensmalltalk-vm/platforms/unix/config$ ./config.sub $(./config.guess)
aarch64-unknown-linux-gnu
cheers
bruce
On 2023-04-04T13:53:22.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi Bruche
one more thing,
could you go to platforms/unix/config/
and download now config.guess/sub?
curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
And give me the output of ./config.guess and ./config.sub $(./config.guess) ?
Best regards -Tobias
On 31. Mar 2023, at 14:08, Bruce O'Neel bruce.oneel@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@gmx.de wrote: Hey Bruce On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
Hi Bruce
On 11. Apr 2023, at 13:59, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Here you go:
~/tmp/opensmalltalk-vm/platforms/unix/config$ curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 49938 0 49938 0 0 57731 0 --:--:-- --:--:-- --:--:-- 57665 ~/tmp/opensmalltalk-vm/platforms/unix/config$ curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 35818 0 35818 0 0 37349 0 --:--:-- --:--:-- --:--:-- 37349 ~/tmp/opensmalltalk-vm/platforms/unix/config$ ./config.guess aarch64-unknown-linux-gnu :~/tmp/opensmalltalk-vm/platforms/unix/config$ ./config.sub $(./config.guess) aarch64-unknown-linux-gnu
Thanks a bunch. That's gonna be fun xD
I'll see what I can do.
Best regards -Tobias
cheers bruce
On 2023-04-04T13:53:22.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hi Bruche
one more thing,
could you go to platforms/unix/config/
and download now config.guess/sub?
curl -o config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...' curl -o config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;...'
And give me the output of ./config.guess and ./config.sub $(./config.guess) ?
Best regards -Tobias
On 31. Mar 2023, at 14:08, Bruce O'Neel bruce.oneel@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@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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@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@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
Hi Bruce,
On 11. Apr 2023, at 14:05, Tobias Pape Das.Linux@gmx.de wrote:
[…]
On 2023-03-31T13:08:28.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hey Bruce
On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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…
Ok, I whipped up something.
Can you try this branch?
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/pi-aarch64-32bi...
Best regards -Tobias
Best regards -Tobias
cheers
bruce
On 2023-03-30T23:22:16.000+02:00, Eliot Miranda eliot.miranda@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@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
Hi,
Thanks! This works perfectly.
cheers
bruce
On 2023-04-11T15:22:52.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi Bruce,
On 11. Apr 2023, at 14:05, Tobias Pape Das.Linux@gmx.de wrote: […]
On 2023-03-31T13:08:28.000+02:00, Tobias Pape Das.Linux@gmx.de wrote: Hey Bruce On 31. Mar 2023, at 12:03, Bruce O'Neel bruce.oneel@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… Ok, I whipped up something.
Can you try this branch?
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/pi-aarch64-32bi...
Best regards -Tobias
Best regards -Tobias cheers bruce On 2023-03-30T23:22:16.000+02:00, Eliot Miranda eliot.miranda@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@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
That's an issue here for about 2 years. I decided to install a 64bit-Kernel for my 32bit-Raspian – as it was called then – in order to speed up ZFS check sum calculations.
Since than the build-systems tries to build a 32bit-VM with 64bit word-size. Luckily I still have a 32bit installation around.
Just my CHF 0.02,
Gerald
On 3/30/23 20:22, Bruce O'Neel 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
squeak-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Eliot Miranda -
squeak.00＠klix.ch -
tim Rowledge -
Tobias Pape