Has anyone installed compiled apps on Raspberry Pi? I am not a Linux or Raspberry Pi guru and am struggling to figure out how to install applications and then have a “clean” way of updating them when needed. I get the impression that the only (or more or less correct) way is APT but the instructions for that make code signing and notarising by command line on MacOS look like child’s play.
you will give your app others?
for my home Raspberry Pi i manage it via remote desktop from windows.
i add Samba so it appear in my windows network.
other file transfer tool for windows is WinSCP.
or as Anthony said, with ms power shell you can reach your pi via ssh.
the xojo runtime i installed with this shell command
sudo apt-get install libunwind8
I typically just:
- ZIP the build
- Upload via SSH
- Stop old instance
- Set executable
- And run.
It will be an in-house app (installed on 2 raspberry pis) but it will be deployed 1000 km away from where I stay…
The intention is to use a raspberry pi with 7" touch screen (no keyboard and mouse, except for initial configuration). At the moment I use ftp to copy over and install, but updates might have to be done when I am far away.
If this works, I have a second application where we potentially use raspberry pi’s at 100s of locations.
In this case I just use the TeamViewer file transfer. To update; Stop the app, transfer new app (only updates modified files), set executable, run.
Do you test already the app on the touch screen? Xojo has some bugs with them.
and i guess you not get from any of this devices a user login?
i think best practice would be provide a packed source (your ftp),
add this to device and then it need execute some apt-get commands by script or xojo tool.
i guess you not want add your app setup to a default raspberry packed source to spread it around the world.
The 2nd app I would like to add as a default raspberry packed source. The first one not. The first app is urgent, the second is a longer term project.
Do you test already the app on the touch screen? Xojo has some bugs with them.[/quote]
Partially. No problems yet, but I still need to add a QR code reader. I have some flexibility to work around issues. The interface needs to be extremely simple and that is one reason to use a Pi with touch screen and not a PC. QR code reader functionality is more critical than touch screen.
I have a build script that allows me to enter important information like changes and version numbers. It then packs that into a zip file I can give to clients so they can put it on a USB stick. When they insert it into the PI it recognizes it and looks for the specific zip file with my code in it. An update is attempted but will auto revert if not successful. I always leave a copy of Teamviewer so if it all goes bad I can log in and fix it. As I don’t want to expose the PI interface to the user, I have written an interface for connecting to wifi and turning on Teamviewer.
dpkg offers a pretty straightforward way to distribute pre-compiled binaries within a .deb package.
There is the skeleton of a tutorial here If you do not need the systemv / systemd stuff you can just ignore it.
If you have a specific layout that is required, the -P (upper case P) to tar can be your friend. You can configure your layout on a local Pi, create a tarball of the bits using “sudo tar =zcvPf MyApp_X.Y.Z.tgz /Path1 .Path2 /Path3 …” and then when you extract it on the remote Pi, use “sudo tar -zxPvf MyApp_X.Y.Z.tgz” and your parts are all exactly where they should be.
That takes a lot of “user error” out of installations where the “user” is not a Linuxphile.
[quote=475694:@Matthew Stevens]dpkg offers a pretty straightforward way to distribute pre-compiled binaries within a .deb package.
There is the skeleton of a tutorial here If you do not need the systemv / systemd stuff you can just ignore it.[/quote]
I am getting there slowly.
I build a simple “Hello World” app which is a window and a close button.
- Installed dpkg on Mac using brew so can develop packages on my development machine.
- Was able to build the package, transfer to Pi and install - and run it using the file manager…
- Was able to remove the package in full using uninstall function
dpkg -r Hello
I have not checked the upgrade process yet for installing a new version.
That is the good news. What does not work is the .desktop file and a way to add an icon to the menu. I am able to add the executable to the menu and launch it, but not show the application icon.
[quote=476336:@Niels de Boer]
That is the good news. What does not work is the .desktop file and a way to add an icon to the menu. I am able to add the executable to the menu and launch it, but not show the application icon.[/quote]
The .desktop is now corrected: I had a combination of minor errors in the .desktop files (some additional spaces seem to be the problem) as well as one additional step was needed which was to restart the lxde environment link text after the package install.
The attached link is the demo project and package file structure which I tested if anyone is curious:
To build the package, use
dpkg-deb -b Hello-1.0_0
from the base folder. Transfer Hello-1.0_0.deb with FTP to the Downloads folder on Pi and then install using
sudo dpkg -i Hello-1.0_0.deb
Once installed, reset lxde environment on the Pi
@Niels de Boer - please mark your message above as the answer
@Jason Parsley - please pin this under Linux as Niels’ answer is a very helpful tip.
Just to note: on the mac, one more step is needed: you need to delete the .DS_Store files before building the package:
find ~/projectdir/setup/pi/packagename -iname .DS_Store -delete
dpkg-deb -b packagename[/code]
I created a small script to do this. If you don’t do it you run into problems when doing an update (first install is ok, but then installing second package is not).
On the pi I have a small update script
sudo dpkg -i packagename.deb
This makes updates easy.
One note on this -
If you don’t open the app folder on the Mac before you copy it over, the .DS_Store file(s) won’t be created.
Very interesting but I can’t understand why Xojo won’t consider ARM with 64 bits?
I can understand that many years ago, when there were only 32-bit Raspberry PI 1 and 2, it was early, but now that there are not only 64-bit Raspberry PI 3 and 4, but also the 64-bit operating system has arrived.
I don’t know why attention is missing for this market. Personally, I recently had to switch to other competing systems for this reason, although I loved XOJO, I initially waited but then got discouraged. I hope the XOJO technicians understand that there is not only Raspberry PI but also the entire NVIDIA series such as Nvidia NANO, Nvidia TX1 / TX2, the JETSON AGX XAVIER series and the latest JETSON XAVIER NX which are fantastic computers.
And we must not forget all ARM computers like:
- ASUS Tinker Board S
- Rock64 multimedia card
- Banana Pi M64
- Orange Pi Zero
- VIM2 SBC of Khadas
- Helios64 from Kobol
- Intel NUC
- PINO A64
Please, dear Xojo technicians, consider developing this fantastic cross-platform development tool also for ARM with 64 bit
On System Requirements System requirements for current version — Xojo documentation
In the Desktop Apps System Requirements section Raspberry PI 64-bit ARMv7 CPU seems to be supported
But it not very clear and its not explained how!
Pi 2, 3 and 4 running:
Raspbian Jessie with Pixel
Other single-board computers that are compatible with a 32-bit or 64-bit ARMv7 CPU may also work, but are not officially supported. Raspbian is the only supported OS
Could somebody help us?
42794 - Add 64 bit ARM Linux Build Support
Feedback Case #42794
Xojo apps for ARM and 32bit apps. If you are running the normally released versions of the 32bit ARM Linux on them, the apps built with Xojo will run - even though the ARM processors are 64bit. The only caveat is that you MUST manually install libunwind as it may not be installed by default.
In my environment, I’ve gotten Xojo apps running on Pi 3 and 4 running the Raspbian 32bit and Raspberry Pi OS 32bit versions. I’ve also had success on a wide range of other ARM SoC boards as long as they were also running a 32bit OS and had libunwind installed.
The reason that we’re asking for 64bit support is that many of the SoCs are arriving with full 64bit version s of Linux as their primary OS and they no longer include the 32bit libraries that a 32bit app needs to run.