I followed a blog titled Creating an Electron Application for the Raspberry Pi, regarding starting an Electron app in Raspberry Pi using the Buster OS and got it to compile.
But when it came to building the application, using the electron-builder, I keep getting the error of cannot execute... after running the command electron-builder --dir --armv7l --linux deb and can't figure what the issue is. I've attached the error
Sorry to be 6 months late to the party, but I also just tried to create an Electron app to run on the Raspberry Pi.
It turns out that while Electron runs fine on Arm processors, there are a bunch of problems with building an Electron app via electron-builder on an Arm processor.
The error that you are seeing is just the opening of the rabbit-hole.
Most of the issues appear to be due to electron-builder having apparently been implemented on an x86 machine, with no real care having been taken to make sure that it works on any other architecture - x86 is just pretty-much assumed.
So, for me, the answer was to build the Arm target on an x86 Linux machine, using exactly the same command-line that you used.
So far, I have found that I can build for OS X and Windows on OS X, for Linux x86, Linux Arm, OS X, and Windows on Linux x86. I don't have Windows machine, so I'm not sure what actually works there.
Code signing is yet another rabbit hole....
Related
I downloaded clarinet from here and am following the installation guide, however I get this error when installing on a raspberry pi:
failed to add native library/home/pi/clarity/clarinet/target/release/gn_out/obj/librusty_v8.a: file too small to be an archive
Does anyone know how to fix this/install clarinet on a raspberry pi?
without knowing much about your environment, to build on arm, there are few things you should be aware of:
there is no musl support, clang is probably best (https://github.com/denoland/rusty_v8/issues/49, I know it says x86_64, but probably same issues on arm)
there is no prebuilt arm binaries (https://github.com/denoland/rusty_v8/releases/)
so you'll probably need to build rusty_v8 from source
I am new to Unity and from my PC (MAC) i have created 3 builds of my project (1-MAC, 2-Windows x86_64, 3-WebGL)
I state that my version of Unity Hub is 2.4.2 and my Unity version is 2019.4.18f1
When i start my game on mac everything works fine (obviously starting the build for mac), later I put the x86_64 windows build in a compressed folder and then transferred it into a USB, to try the game from another pc (win 10 PRO). In this PC the same version of unity was already present.
So far, so good.
The problem starts when I take the same USB with the same files, which, as previously said on win10 pro work, I put them on a win10 home (32 bit) and when I try to start the .exe it gives me this error "This app can't run on your PC. To find a version for your PC, check with the software publisher "
Looking on the internet I tried to get around the problem they change the local settings policy, but the result is the same :(
These are the files inside my compressed folder
And these are my build settings
I thank whoever will be able to help me and I apologize for my bad English
You say your other PC is 32 bit!
That's your issue!
You are building for the Architecture
x86_64 => 64-bit CPU
It does not mean 32 or 64 bit.
To run it on a 32 bit system you have to build for x86 instead.
See Unity Manual - PC, Mac & Linux Standalone build settings
I have a desktop application (built with NW.js and the node-webkit-builder) that runs smoothly on Windows and OS X, however, I can't seem to open the executable on the Raspberry Pi. The NW.js builder outputs the 32- and 64-bit Linux distributions, as well, that I assume should operate on Raspbian or Ubuntu MATE. However, I keep getting the error:
cannot open the application since there isn't a readable executable.
Even after chmod +x the application, it doesn't work.
raspberry pi use arm architecture, you may checkout this: https://github.com/toxygen/armhf-node-webkit
Rasp Pis are using ARM processors and not the x32 and x64 processors the NW.js binaries support.
You will need to download a prebuilt for the ARM or build it yourself.
Here is a link to a prebuilt for 0.12.0. You will package your app just like you would on a x32/x64 machine.
Unfortunately ARM is still not an officially supported platform and if you wish to have prebuilts you will have to depend on community members/contributors.
You need the binary port of NW.js (node-webkit) for Raspberry Pi.
I have just created a repository with the node-webkit binary port that runs on Raspbian, tested and working on Raspberry Pi 1 and Raspberry Pi 3 so it is ARMv6 and ARMv7 compatible.
Here you can check it: https://github.com/jalbam/nwjs_rpi
I was trying to play with several tiny operating systems in an emulator but got stuck with Contiki in QEMU. Ideally the compiled executable should be run as a kernel in QEMU. For all OS's I was playing with I used this simple command to run executables in QEMU:
qemu-system-platform -nographic -kernel compiled_executable
In the case of Contiki, QEMU freezes regardless of any target platform the executables are compiled for, even for target platform "native", which according to the documentation, is built with "x86 gcc".
I also tried ARM-based platforms with the same freezing issues. If I specify a correct CPU model (e.g. cortex-m3 for cc2538dk), I received a segmentation fault instead.
I am wondering if I was missing any steps to cause the QEMU to freeze. Does it mean that the compiled executable cannot be treated as kernels (yet), unless I provide some QEMU-specific codes to initialize QEMU as a "board" for Contiki?
The native platform is used to build a "natively" (i.e. on Linux or other OS) executable image of Contiki - an userland app, rather than an OS kernel.
We've inherited some legacy software that we need to run quite urgently. It was written in Lisp and we don't have the source code (developer is dead), only runs on Mac OS 9 (some bug seems to prevent it running on anything newer) and requires a license dongle to run.
We have an old machine that will run the software, but it is a dinosaur. Ideally, the solution would also provide for remote access as well.
My first thought was to use some kind of emulator on a newer machine, or even a VPS. But I have concerns about how these will work with the USB dongle. Can anyone suggest a solution better than accepting that working with old code sucks and getting on with it?
The most recent hardware I can think is a PowerPC Macintosh, with Mac OS X 10.4 (Tiger). It is the last version of Mac OS X to have the Classic Environment, that will let you run this legacy software.
Alternatively, if you don't have a PowerPC Mac in house, you can look into SheepShaver, a PowerPC emulator, however you'll need a Mac OS install CD.