Objo Studio on Raspberry (Linux Arm)

einhugur

Will there eventually be Objo Studio on Raspberry Pi ? (Linux Arm).

And I guess same goes for Windows Arm.

It really changed everything on Raspberry Pi development when Xojo brought the IDE to Raspberry, you just cant compare running remote debuggers to it.

Same question goes for Windows Arm (even if I am not in that camp) since I imagine it would suck for those that have maybe brand new Windows Arm machine to have to run it in emulation all the time.

bgrommes

einhugur Not to mention Linux ARM generally. As I understand it the Pi is really just running Debian Trixie at the moment. Is there anything so special about Raspberry PI, apart from maybe a tendency to less RAM, that you would need to test a specific Raspberry PI target? I honestly don't know -- just curious.

I notice there does seem to be a trend toward buying things like used thin clients in preference to the Pi 5, which some consider over-priced and less in the original spirit of the series.

einhugur

bgrommes

Linux Arm general is just same as Raspberry Pi.

(I almost always run the Xojo Raspberry IDE on Armbian for example)

Mentioning Raspberry Pi in downloads or ads is usually just sales slogan.

IDE on Linux arm (Rasberry for example) helps bring in tinkerers which again help spread word of Objo.

einhugur

Thin clients dont really replace the tinkerer side of Raspberry and similar boards.

Raspberry people are connecting sensors and all sorts of automations.

At my work we are putting Raspberries for example inside gates at swimming pools to control the ticketing.

Garry

I’d like to offer native Studio builds for both Linux ARM64 and Windows ARM64. Objo already supports building applications for those targets, and I’ve also successfully built and exercised Studio itself on Linux ARM64 internally. The current public Linux and Windows IDE downloads are still x64.

For Raspberry Pi, I would initially target a 64-bit OS. It would be the same Linux ARM64 build used on other compatible machines, but I would still want to test Studio on actual Pi hardware before claiming support, including checking graphics and memory use.

I agree that having the full IDE available locally would be useful for people working with sensors and automation. There is already some groundwork in place, but I don’t have a release date to promise yet. The main challenge is the test surface and build time. It already takes many hours to get a Studio build out of the door just in packaging and compilation. I also manually test the IDE on the supported platforms. If there is enough user demand for these platforms there is no technical reason I can't offer them.

einhugur

Garry

Its really only 64 bit OS you need to target.

32 bit Raspberry Pi (and clones) is dying legacy thing and those boards are old and weak and not really the right candidate high level heavy framework.s

einhugur

I would say automate the build (which you probably do already) and just mark less mainstream IDE's as less tested or untested. And use the community to test those. While your alone at all this its impossible to test every single built of many platforms.

RolfG

I would gladly test since I have a lot of raspberries running here and remote with sensors or as monitoring stations with dual displays.

jalih

einhugur I still use some ST32MP157 based boards for my home automation projects. Mostly, I use ST32MP257 based boards, as it's fast enough with hardware acceleration and RPI5 is too powerful for my purposes and heats too much.

Garry

OK, you've twisted my ARM (pun intended 🙂).

I will add Linux ARM Studio builds to the next publishing run of Studio. I will mark it as experimental as I don't have a Linux ARM setup here to easily test it with so apologies in advance if it's a little rough.

https://feedback.objo.dev/feature/1760

TheTomas

wow I could run Objo on my Linux ARM Tablet then ;-)
https://forum.objo.dev/d/1198-linux-arm

einhugur

I will try to test it a little bit for you. I have wide range of Arm64 boards.

Running Raspberry OS, Armbian and few other kinds of Linuxes.

madamov

I will test ARM Linux in my virtual machine on my Macbook Pro M2.

bgrommes

madamov I will test ARM Linux in my virtual machine on my Macbook Pro M2.

Similarly here, I have Debian running on a Macbook Pro M5.

I am still going to set up Debian in a VM on an Intel Windows 11 Pro host, when I get a Round Tuit. Anyone got a spare one?

Garry

This has been implemented for the next release 🙂

bgrommes

@Garry Installed and running fine on Linux ARM (Debian Trixie, 16G VM on Apple M5). Simple command line app compiled and ran.

Won't have much opportunity to stress it for awhile but plan to use it for testing soon.

madamov

madamov I will test ARM Linux in my virtual machine on my Macbook Pro M2.

I found some time to test this and it is working perfectly. However, I got an error when trying to publish on Linux:

[Error] An error occurred trying to start process '/home/madamov/git/Matricula/Publish/Matricula/Linux-x64/Matricula-linux-x64.AppImage' with working directory '/tmp/objo_linux_verify_fd37ee0c4c374adf8e020854b76ade8a'. Exec format error

This is what Codex replied about it:

This is a CPU architecture mismatch: the publisher is trying to run an Intel/AMD x64 AppImage on ARM Linux.

I confirmed locally:

Your machine reports aarch64 (ARM64).
Matricula-linux-x64.AppImage contains an x86-64 executable.
Your publish configuration includes both linux-x64 and linux-arm64.

The /tmp/objo_linux_verify_... directory suggests the publisher is launching the generated AppImage as part of verification. Linux rejects it before Matricula starts.

For publishing on this machine, select Linux ARM64 only. If you need both architectures, the publisher should generate both packages but run verification only for the host’s architecture—or verify x64 on an x64 machine. Attempting native x64 verification on ARM looks like a publisher issue.

Changing executable permissions won’t fix this error.

Garry

Thanks for testing this. Good to hear Studio is running well on ARM Linux 🙂

Codex’s diagnosis was correct. Studio was trying to execute the x64 AppImage’s extraction command on your ARM64 VM during post-publish verification, causing the Exec format error.

I’ve fixed this for the next release. Publishing will still create both selected architectures, but extraction and embedded signature checks will only run when the target CPU matches the host. The publish results will clearly flag any checks that need to run on a matching Linux machine.

Until that release, select Linux ARM64 only, or use the portable .tar.gz format if you need both architectures.

Tracked and fixed here.