FreeShow 1.1.7 linux arm64 startup issue

[odlg]

Trying to start FreeShow 1.1.7 on arm64 Linux show this error, and it does not start up.

$ ./Downloads/FreeShow-1.1.7-arm64.AppImage 
A JavaScript error occurred in the main process
Uncaught Exception:
Error: /tmp/.mount_FreeShLjZUnb/resources/app.asar.unpacked/node_modules/grandiose/build/Release/grandiose.node: cannot open shared object file: No such file or directory
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1810)
    at Module._extensions..node (node:internal/modules/cjs/loader:1205:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:5:2037)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:829:12)
    at c._load (node:electron/js2c/asar_bundle:5:13343)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at bindings (/tmp/.mount_FreeShLjZUnb/resources/app.asar/node_modules/bindings/bindings.js:112:48)
    at Object.<anonymous> (/tmp/.mount_FreeShLjZUnb/resources/app.asar/node_modules/grandiose/index.js:18:34)

Running from the dev branch works fine.

[odlg]

Btw, to make releases more stable, I would suggest to make pre-releases and have them available for 1–2 weeks and only make minimal changes to them in that period. Pre-releases should not pop up when released in the app.

[vassbo]

Did you not get this in the previous version? Looks like NDI is not supported on Linux arm64, but should work on Linux x64.

I have thought about pre-releases, so I finally changed it this update actually to not show those in the app popup.

[odlg]

Yes, the arm64 linux AppImages worked from 1.1.1 or so until 1.1.6. But 1.1.7 gives above error.

[vassbo]

Okay, does it work when NDI is off, or not at all? Also, if you build the dev version manually does it work then, or do you get the same error?

[odlg]

It does not start at all. When I do npm install and npm start on the dev branch it starts and works fine.

[odlg]

I checked the file node_modules/grandiose/build/Release/grandiose.node in my git checkout. That is a arm64 binary file. ./node_modules/grandiose/build/Release/grandiose.node: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1e25a5adc7c0a06166b456d5ec9d2c70e540c28a, not stripped

In 1.1.7 arm64 linux appimage release it is a x86_64 file: resources/app.asar.unpacked/node_modules/grandiose/build/Release/grandiose.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=106f1718cc4cef32ea226b4a7eff5354d4e9eb34, not stripped

But it was also a x86_64 binary in earlier linux arm64 appimage releases.

[vassbo]

Okay, thanks. I have no idea why this has suddenly happened, not much has changed that should affect this. 🤔

[odlg]

If I build a release on arm64, the arm64 AppImage works. If I build on x64 the arm64 AppImage does not work.

Building outputs this:

> electron-builder

  • electron-builder  version=24.12.0 os=6.9.1-1-default
  • loaded configuration  file=package.json ("build" field)
  • writing effective config  file=dist/builder-effective-config.yaml
  • rebuilding native dependencies  [email protected], [email protected] platform=linux arch=x64
  • packaging       platform=linux arch=x64 electron=21.4.4 appOutDir=dist/linux-unpacked
  • skipping "afterSign" hook as no signing occurred, perhaps you intended "afterPack"?
  • building        target=AppImage arch=x64 file=dist/FreeShow-1.1.7.AppImage
  • rebuilding native dependencies  [email protected], [email protected] platform=linux arch=arm64
  • building        target=deb arch=x64 file=dist/freeshow_1.1.7_amd64.deb
  • adding autoupdate files for: deb. (Beta feature)  resourceDir=/home/od/src/FreeShow/dist/linux-unpacked/resources
  • packaging       platform=linux arch=arm64 electron=21.4.4 appOutDir=dist/linux-arm64-unpacked
  • skipping "afterSign" hook as no signing occurred, perhaps you intended "afterPack"?
  • building        target=AppImage arch=arm64 file=dist/FreeShow-1.1.7-arm64.AppImage
  ⨯ GitHub Personal Access Token is not set, neither programmatically, nor using env "GH_TOKEN"

So it seems to be rebuilding grandiose for x64 and arm64.

Searching for all *.node files in the tree ---

find . -name \*.node
./node_modules/@rollup/rollup-linux-x64-gnu/rollup.linux-x64-gnu.node
./node_modules/@rollup/rollup-linux-x64-musl/rollup.linux-x64-musl.node
./node_modules/grandiose/build/Release/obj.target/grandiose.node
./node_modules/grandiose/build/Release/grandiose.node
./node_modules/jazz-midi/bin/10_15/linux64/jazz.node
./node_modules/jazz-midi/bin/10_15/linuxa7/jazz.node
./node_modules/jazz-midi/bin/10_15/macos64/jazz.node
./node_modules/jazz-midi/bin/10_15/win32/jazz.node
./node_modules/jazz-midi/bin/10_15/win64/jazz.node
./node_modules/jazz-midi/bin/11_15/linux64/jazz.node
./node_modules/jazz-midi/bin/11_15/linuxa7/jazz.node
./node_modules/jazz-midi/bin/11_15/macos64/jazz.node
./node_modules/jazz-midi/bin/11_15/win32/jazz.node
./node_modules/jazz-midi/bin/11_15/win64/jazz.node
./node_modules/jazz-midi/bin/linux64/jazz.node
./node_modules/jazz-midi/bin/linuxa7/jazz.node
./node_modules/jazz-midi/bin/macos64/jazz.node
./node_modules/jazz-midi/bin/macosa64/jazz.node
./node_modules/jazz-midi/bin/win32/jazz.node
./node_modules/jazz-midi/bin/win64/jazz.node
./node_modules/sqlite3/lib/binding/napi-v6-linux-glibc-x64/node_sqlite3.node
./node_modules/sqlite3/lib/binding/napi-v6-linux-glibc-arm64/node_sqlite3.node
./dist/linux-unpacked/resources/app.asar.unpacked/node_modules/grandiose/build/Release/grandiose.node
./dist/linux-arm64-unpacked/resources/app.asar.unpacked/node_modules/grandiose/build/Release/grandiose.node

It strikes me that all files, except grandiose.node has different files for each architecture. Perhaps including the architecture in the path to grandiose.node would help? Or perhaps build the arm64 AppImage on a arm64?

[vassbo]

Thanks. The weird part is how this has worked previously. But I guess I can set up GitHub Actions to build a custom build for arm64 Linux. Or maybe better to include the architecture, but not sure how to do that, any ideas?

[odlg]

I have been trying to find the reason that grandiose.node is in x64 format. The other modules simply downloads precompiled binaries for different platforms. According to https://gyp.gsrc.io/docs/UserDocumentation.md#Cross_compiling there is limited cross-comile support in node-gyp. Also doing it would require the build server to have arm64 compiler etc installed, I guess it does not have that. Would it be possible to setup GitHub Actions to do it? As to why it worked previously - I guess that earlier when starting FreeShow, it did not attempt it initialize the grandiose.node library.

[vassbo]

Okay, thank you! 😊

[vassbo]

https://github.com/ChurchApps/FreeShow/pull/602

[vassbo]

Does this work now? https://github.com/ChurchApps/FreeShow/releases/tag/v1.1.8

[odlg]

It does not work. Not exactly the same error message.

Uncaught Exception:
Error: /tmp/.mount_FreeShTM3mlB/resources/app.asar.unpacked/node_modules/grandiose/build/Release/grandiose.node: cannot open shared object file: No such file or directory
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1810)
    at Module._extensions..node (node:internal/modules/cjs/loader:1205:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:5:2037)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:829:12)
    at c._load (node:electron/js2c/asar_bundle:5:13343)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at bindings (/tmp/.mount_FreeShTM3mlB/resources/app.asar/node_modules/bindings/bindings.js:112:48)
    at Object.<anonymous> (/tmp/.mount_FreeShTM3mlB/resources/app.asar/node_modules/grandiose/index.js:18:34)

Building the appimage myself with npm installand npm run release works fine.

[vassbo]

Okay, here what I now. The machine itself looks like this: @ /opt/hostedtoolcache/node/20.14.0/x64

At first this command is run: electron-builder install-app-deps Output: rebuilding native dependencies [email protected], [email protected] platform=linux arch=x64

Then this (new): npm run release:arm64 Output rebuilding native dependencies [email protected], [email protected] platform=linux arch=arm64

I would have thought that the last one would install the correct file, but I guess npm install on x64 is the problem. I could not find a way to change that to arm64.

[MrShinyBoots]

I can confirm this issue still exists with the Appimage

[odlg]

I will try to fix it.

[vassbo]

@odlg Does it make any difference if you replace the vassbo/grandiose#fa2ac4b package with vassbo/grandiose#da61000 or hopejr/grandiose#50ffdfb?

[odlg]

I did some work here https://github.com/odlg/FreeShow/ It had hoped I could find a simpler way, but this mostly works. There are a few issues I still hope to fix:

• It requires changes to package.json so it only builds the AppImage (it fails when attempting to build .deb file)
• It ends with a zip file containing the AppImage file - currently it has a fixed name, I guess current version could be included in that filename.

[vassbo]

Okay, awesome! Would be nice to have those fixed, yes. :)

[MrShinyBoots]

Are there any updates on fixing this issue? - many thanks :)

[odlg]

@vassbo GitHub actions now builds a zip file with a working AppImage file for arm64 with https://github.com/odlg/FreeShow/blob/main/.github/workflows/release.yml Above uses emulated arm64, so it is slow. According to https://github.blog/news-insights/product-news/arm64-on-github-actions-powering-faster-more-efficient-build-systems/ native arm64 builds should be available for free late 2024.

[vassbo]

Awesome! Thank you for all the help. 😃 If you think it's ready to be used please create a pull request with the change if you don't mind.

The GitHub Linux arm support might mean that this is no longer needed within a few months, but I guess this will do for now or what do you think @odlg?

[vassbo]

@odlg Please try it out: https://github.com/ChurchApps/FreeShow/releases/tag/v1.2.7-beta.2 I also tweaked the grandiose package so NDI might also work?

[odlg]

@vassbo The AppImage works on Linux arm64. 😀 NDI can not be enabled.

[vassbo]

Great! 🥳 I forgot to change it there, but if you go to Media>Screens>NDI, do you get any inputs if you have any?

[odlg]

@vassbo It detects NDI input, shows a frame with name of the sender and then crashes.

[vassbo]

Okay, thanks. I'm guessing that means the frame sender/receiver does not work on arm64!

If you would like you can try the dev version to test out the sender as well, and to see if you get any errors with the crash?

[vassbo]

Maybe this is related: https://github.com/ChurchApps/FreeShow/issues/800 In that case the NDI inputs does not work on mac arm64 either!

[odlg]

@vassbo I can not successfully build currently:

...
src/server/output_stream/main.ts → build/electron/output_stream/client.js...
created build/electron/output_stream/client.js in 549ms

> [email protected] build:electron:prod
> cross-env NODE_ENV=production tsc --p ./tsconfig.electron.prod.json

src/electron/output/ppt/presentation.ts:95:51 - error TS2554: Expected 1 arguments, but got 2.

95         currentSlideshow = new Slideshow(program, isProd)
                                                     ~~~~~~


Found 1 error in src/electron/output/ppt/presentation.ts:95

ERROR: "build:electron:prod" exited with 1.