64 bit Raspbian apps

[graham.reeds]

I was unsure of where this should go in so I have placed it under 'General'.

One of the pieces of software I use is built using CMake and increasingly there is a use of 'CMAKE_SIZEOF_VOID_P' throughout the code. Now I have gone through and commented these out but it is annoying that every new release I have to manually edit the build. It would be nice if I could use a 64bit version of CMake (and potentially other 64 bit apps) and avoid having to do this manual editing.

Is there a experimental distribution of 64bit apps to go along with the 64bit Raspbian dist?

[fruitoftheloom]

I was unsure of where this should go in so I have placed it under 'General'.

One of the pieces of software I use is built using CMake and increasingly there is a use of 'CMAKE_SIZEOF_VOID_P' throughout the code. Now I have gone through and commented these out but it is annoying that every new release I have to manually edit the build. It would be nice if I could use a 64bit version of CMake (and potentially other 64 bit apps) and avoid having to do this manual editing.

Is there a experimental distribution of 64bit apps to go along with the 64bit Raspbian dist?

Raspbian is 32bit Userland, though you can have either a ARM32 or ARM64 Kernel.

[Heater]

Something seems wrong here. Surely cmake should define CMAKE_SIZEOF_VOID_P appropriately and the code should build on 32 bit and 64 bit platforms. Without the need to go and comment them out.

I have been building and running 64 bit code on the 32 bit raspbian but with a 64 bit kernel installed and sakaki's nspawn setup : https://www.raspberrypi.org/forums/view ... 3&t=232417

Although I did not go for the full 64 bit desktop experience, only a 64 bit command line shell that I could build 64 bit TUI code in.
Sadly I can't find the thread where sakaki explains how to do that.

[jahboater]

Something seems wrong here. Surely cmake should define CMAKE_SIZEOF_VOID_P appropriately and the code should build on 32 bit and 64 bit platforms. Without the need to go and comment them out.

+1.
Its perfectly easy in this day and age to write C/C++ code that's portable between 64-bit and 32-bit platforms without any edits.

[sakaki]

Although I did not go for the full 64 bit desktop experience, only a 64 bit command line shell that I could build 64 bit TUI code in.
Sadly I can't find the thread where sakaki explains how to do that.

To install a 64-bit Debian Buster environment on your RPi3/4 (running Raspbian), per the fuller instructions here, you should first run:

Code: Select all

pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get -y upgrade

to bring your system up to date (as is good prep for any install).

And then (if you are on a 'with desktop' Raspbian system), simply issue:

Code: Select all

pi@raspberrypi:~ $ sudo apt-get install -y raspbian-nspawn-64

and follow the prompts, rebooting if instructed.

Or (on a 'lite', CLI-only) Raspbian system, you should instead issue:

Code: Select all

pi@raspberrypi:~ $ sudo apt-get install -y --no-install-recommends raspbian-nspawn-64

to install without bringing in any unwanted GUI-based dependencies.

Once installed, you can then enter a 64-bit terminal either from the menu item (if on a desktop-based system):



or by issuing, at a standard 32-bit terminal (works on both desktop and 'lite' systems):

Code: Select all

pi@raspberrypi:~ $ ds64-shell
pi@debian-buster-64:~ $

Ctrl-d will take you back to the regular 32-bit prompt again.

The 'sidekick' 64-bit system is vanilla Debian Buster, so e.g. apt etc. works.

hth, sakaki

[Heater]

Thank you sakaki. I was wondering where those instructions had got to. That 64 bit shell worked very nicely. Great job.

[graham.reeds]

Something seems wrong here. Surely cmake should define CMAKE_SIZEOF_VOID_P appropriately and the code should build on 32 bit and 64 bit platforms. Without the need to go and comment them out.

You would think? The test is if CMAKE_SIZEOF_VOID_P != 8 it just gives up. The version of cmake that you can apt-get just gives 4 as the sizeof VOID_P. Hence why I need to comment it out and if there was a repository of 64bit apps.

Sorry about not replying sooner - I seemingly was never subscribed to this topic.

[Heater]

You would think? The test is if CMAKE_SIZEOF_VOID_P != 8 it just gives up. The version of cmake that you can apt-get just gives 4 as the sizeof VOID_P. Hence why I need to comment it out and if there was a repository of 64bit apps.

Hmm...

Presumably if someone has gone to the trouble of testing that sizeof void is 8 before it will build anything there is a good reason for it. I have run across a few programs that require 64 bit pointers, for example when they map many gigabytes of file into memory space. For those cases there is no point in trying to build it for 32 bits anyway.

Of course they could just be dolts who don't care to write portable code.

Lucky we now have a nice way to build and run 64 bit code thanks to the great work of sakaki.

[ejolson]

Of course they could just be dolts who don't care to write portable code.

In order to learn how to write portable code, even a dolt needs access to a variety of hardware architectures and compilers. Experience with many of these can be obtained using emulation on a single Pi. Among others, qemu can do

• IA-32 (x86) PCs
• x86-64 PCs
• MIPS64 Release 6 and earlier
• Sun's SPARC sun4m
• Sun's SPARC sun4u
• PowerPC (PReP and Mac)
• RISC-V

For experience with historic hardware SIMH can provide

• Altair 8008
• AT&T 3B2
• CDC 1700
• Data General Nova, Eclipse
• DEC Alpha
• DEC PDP-1, 4, 7, 8, 9, 10, 11, 15
• VAX 11/730, 750, 780, 8600
• HP 2116, 2100, 21MX, 3000
• Honeywell H316, H516

and many more. It is also possible to emulate almost any classic 8-bit home computer using a Pi, including the Atari, Apple, PET, C64, BBC Micro and so forth.

The availability of all these emulators means there's absolutely no excuse not to write fully verified architecture, endian and operating system independent code. An example of a recently written C program that complies without change for

• PDP-11
• PET
• Pi
• x86

and likely many more is discussed at

viewtopic.php?t=257317&start=75#p1573277

Surprisingly, the cmake makefile maker and all its complexity is unsurprisingly unportable. In addition to sensible coding practices, creating portable software further involves choosing the right tools--popular, widespread and simple enough that they can be ported if necessary.

On the other hand, now that 64-bit Linux has (along with COVID-19 and nspawn) taken over the world, it's possible being portable is no longer important, even to something as similar as 32-bit Raspbian.

[graham.reeds]

The shell inside the shell works. Question is: Why use raspbian at all and why not just use ds64 directly?

[6by9]

The shell inside the shell works. Question is: Why use raspbian at all and why not just use ds64 directly?

Because it doesn't work on Pi0, 1 (ARM1176), or earlier 2's (A7). Only late Pi2s, Pi 3s (A53), and Pi4s (A72) are 64 bit processors.

[dickon]

The shell inside the shell works. Question is: Why use raspbian at all and why not just use ds64 directly?

Feel free to. If you don't need any of the Pi-specific accelerations (video, mostly) then a standard 64b Debian userland works nicely.

[graham.reeds]

But I am not interested in those for my use case.

The original problem was that cmake was reporting that the size of pointer was 4 bytes. The author of a software I use fairly often uses that to make sure it is being compiled on a 64 bit system (it is cross platform on Mac, Win, Linux). Commenting them out allows the software to compile fine but was awkward as I had to make the change every time a new release came out.

Hence why I asked if there was a repo with 64bit apps in it.

I had seen the nspawn project but it had a rather complex install method (glad to see that has changed), but now a boot to terminal needs to be changed to immediately spawn another terminal?

Hence why boot into raspbian at all and simply boot into the ds64 shell?

PS: I love the Pi (I have a couple of 2's, half a dozen Pi3b+ (for a failed virtual wind tunnel project), and a couple of Pi4's plus a couple of NanoPi (also for the virtual wind tunnel project)). On my desk I have a Pi3 and Pi4 in ArmorCase and a PiZero which I was making in a PiHole.