search

gorilla-devs / GDLauncher

GDLauncher is a simple, yet powerful Minecraft custom launcher with a strong focus on the user experience
https://gdevs.io
GNU General Public License v3.0
1.21k stars 254 forks source link

Trouble Building on Arm64 #727

Closed theofficialgman closed 1 year ago

theofficialgman commented 3 years ago

Describe the bug When attempting to build on arm64 (in this case a nintendo switch), the build fails. Logs: 2020-12-21T20_27_01_716Z-debug.log 2020-12-21T20_27_01_772Z-debug.log 2020-12-21T20_27_01_824Z-debug.log

System: NVIDIA Jetson UNKNOWN Jetpack 4.3 [L4T 32.3.1] NV Power Mode: Locked_MAX - Type: 7 jetson_stats.service: active Board info: Type: UNKNOWN SOC Family: tegra210 - ID:33 Module: UNKNOWN - Board: UNKNOWN Code Name: icosa Boardids: 2595:0000:A0 CUDA GPU architecture (ARCH_BIN): NONE Serial Number: 1234 Libraries: CUDA: NOT_INSTALLED cuDNN: 7.6.3.28 TensorRT: 6.0.1.10 Visionworks: NOT_INSTALLED OpenCV: 4.1.1 compiled CUDA: NO VPI: NOT_INSTALLED Vulkan: 1.1.70

OS: Ubuntu 18.04.5 LTS aarch64 Host: icosa Kernel: 4.9.140+ Shell: bash 4.4.20 DE: GNOME 3.28.4 WM: GNOME Shell Terminal: gnome-terminal CPU: (4) @ 1.989GHz Memory: 1429MiB / 3969MiB

TOLoneWolf commented 3 years ago

if I recall correctly to run the build you have to use a environment variable RELEASE_TESTING=true then npm run release

theofficialgman commented 3 years ago

hmm that doesn't seem to produce any better results

do note that this is my first time using node.js and rust so I could be doing something wrong in the process.

I'd be very appreciative if anyone could verify the readme build steps for me.

Ladvace commented 3 years ago

Try npm run build

blarfoon commented 3 years ago

@theofficialgman Could you provide your logs using RELEASE_TESTING=true in the .env file?

theofficialgman commented 3 years ago

logs are the exact same when adding that environment variable (export RELEASE_TESTING=true)

seems to be an issue with the build script for electron on arm64. note it can be done, as seen by https://github.com/SpacingBat3/electron-discord-webapp which does work

cobalt2727 commented 3 years ago

Gonna throw my two cents in. I'm trying to build on a Pi 4 Model B (yes, I know it won't perform well even if I get it built successfully). For starters, here's my system info:

OS: Ubuntu MATE 20.10 aarch64 Host: Raspberry Pi 4 Model B Rev 1.4 Kernel: 5.8.0-1011-raspi Uptime: 2 hours, 32 mins Packages: 2707 (dpkg), 45 (flatpak) Shell: bash 5.0.17 DE: MATE 1.24.1 WM: Metacity (Marco) Terminal: mate-terminal CPU: BCM2835 (4) @ 1.500GHz Memory: 1606MiB / 7631MiB

Worth mentioning I've correctly installed NodeJS, Rust, and Python correctly, as far as I'm aware. Also, the .env var RELEASE_TESTING was already set to true by default...

I had to make a few modifications to /GDLauncher/scripts/preinstall.js to get things going: -set REQUIRED_NODE_VERSION to 'v14.15.4' to match my installed packages -set REQUIRED_NODE_ARCH to 'arm64' for, well, obvious reasons

All my logs can be found attached 2021-01-13T04_24_38_089Z-debug.log 2021-01-13T04_24_38_154Z-debug.log 2021-01-13T04_24_38_214Z-debug.log terminal_output.txt

AshtakaOOf commented 3 years ago

hello you don't need to build GDLauncher i think you can just use the AppImage it will work fine and your raspberry 4 is one of the most powerful raspberry on the market

cobalt2727 commented 3 years ago

hello you don't need to build GDLauncher i think you can just use the AppImage it will work fine and your raspberry 4 is one of the most powerful raspberry on the market

The AppImage (and the deb) are x86_64 only. Also, the Pi 4 may have a good CPU but the GPU is way too weak to pull its own weight for games.

NoozAbooz commented 3 years ago

The AppImage (and the deb) are x86_64 only. Also, the Pi 4 may have a good CPU but the GPU is way too weak to pull its own weight for games.

The GPU is fine sorta, it's the CPU which is limited. Seems like with some optimisations you can juice a 20 or 60 FPS out of it

theofficialgman commented 3 years ago

Update: I've been able to build GDLauncher successfully for arm64 (I think) but can't run it because of the precompiled murmur2.node and nsfw,node files included in this repo.

Could a dev (@killpowa) advise me how to go about building native versions of these required libraries? I think I need a proper binding.gyp file to do so in conjunction with using node-gyp

theofficialgman commented 3 years ago

@killpowa I apologize if this is a double ping. not sure if editing in a @ reference updates that person or not.

theofficialgman commented 3 years ago

oh I see.. this was the old repo where I can no longer get the source https://github.com/gorilla-devs/murmurhash32 ... thats not too nice found a fork and can build from there with npm but that fork must have been out of date... because I just get this undefined symbol error now. or maybe I'm missing some dependencies on my install?

A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot open /home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/native/linux/murmur2.node: Error: /home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/native/linux/murmur2.node: undefined symbol: _ZN2v811ArrayBuffer11GetContentsEv
    at Object.eval (webpack-internal:///./public/native/linux/murmur2.node:1:236)
    at eval (webpack-internal:///./public/native/linux/murmur2.node:2:30)
    at Object../public/native/linux/murmur2.node (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:2217259)
    at t (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:124)
    at eval (webpack-internal:///./public/native/murmur2.js:9:11)
    at Object../public/native/murmur2.js (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:2219696)
    at t (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:124)
    at eval (webpack-internal:///./public/electron.js:47:16)
    at Object../public/electron.js (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:2170981)
    at t (/home/garrett/GDLauncher/release/linux-arm64-unpacked/resources/app.asar/build/electron.js:1:124)
theofficialgman commented 3 years ago

In my fork with the previous version of the buildfiles where natives are built instead of supplied as binaries, I get to this point and error out now https://github.com/theofficialgman/GDLauncher

> gdlauncher@1.1.8 postinstall
> npm run rebuild

> gdlauncher@1.1.8 rebuild
> node ./scripts/buildNativeDeps.js

neon info forcing rebuild for new build settings
neon info running cargo
   Compiling memchr v2.3.3
   Compiling lazy_static v1.4.0
   Compiling regex-syntax v0.6.17
   Compiling cc v1.0.50
   Compiling autocfg v1.0.0
   Compiling cfg-if v0.1.10
   Compiling byteorder v1.3.4
   Compiling semver-parser v0.7.0
   Compiling cslice v0.2.0
   Compiling thread_local v1.0.1
   Compiling neon-build v0.3.3
   Compiling num-traits v0.2.11
   Compiling num-integer v0.1.42
   Compiling num-bigint v0.2.6
   Compiling semver v0.9.0
   Compiling aho-corasick v0.7.10
   Compiling murmurhash32 v0.2.0 (https://github.com/gorilla-devs/murmurhash32.git#40164089)
   Compiling regex v1.3.5
   Compiling neon-sys v0.3.3
The following warnings were emitted during compilation:

warning: ar: /home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build/Release/obj.target/neon/src/neon.o: No such file or directory

error: failed to run custom build command for `neon-sys v0.3.3`

Caused by:
  process didn't exit successfully: `/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-fa02a779a648ce32/build-script-build` (exit code: 1)
  --- stdout
  Skipping node-gyp installation as part of npm install.

  > build-release
  > node-gyp build

  make: Entering directory '/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build'
    CXX(target) Release/obj.target/neon/src/neon.o
  neon.target.mk:109: recipe for target 'Release/obj.target/neon/src/neon.o' failed
  make: Leaving directory '/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build'
  TARGET = Some("aarch64-unknown-linux-gnu")
  HOST = Some("aarch64-unknown-linux-gnu")
  AR_aarch64-unknown-linux-gnu = None
  AR_aarch64_unknown_linux_gnu = None
  HOST_AR = None
  AR = None
  running: "ar" "crs" "/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/libneon.a" "/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build/Release/obj.target/neon/src/neon.o"
  cargo:warning=ar: /home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build/Release/obj.target/neon/src/neon.o: No such file or directory
  exit code: 1

  --- stderr
  gyp info it worked if it ends with ok
  gyp info using node-gyp@3.6.2
  gyp info using node@15.14.0 | linux | arm64
  gyp info spawn make
  gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  In file included from /home/garrett/.electron-gyp/13.1.0/include/node/node.h:67:0,
                   from ../node_modules/nan/nan.h:54,
                   from ../src/neon.cc:2:
  /home/garrett/.electron-gyp/13.1.0/include/node/v8.h:1670:79: warning: ?ResolveCallback? is deprecated [-Wdeprecated-declarations]
                                                         ResolveCallback callback);
                                                                                 ^
  /home/garrett/.electron-gyp/13.1.0/include/node/v8.h:8652:51: warning: ?HostImportModuleDynamicallyCallback? is deprecated [-Wdeprecated-declarations]
         HostImportModuleDynamicallyCallback callback);
                                                     ^
  In file included from ../node_modules/nan/nan.h:2884:0,
                   from ../src/neon.cc:2:
  ../node_modules/nan/nan_typedarray_contents.h: In constructor ?Nan::TypedArrayContents<T>::TypedArrayContents(v8::Local<v8::Value>)?:
  ../node_modules/nan/nan_typedarray_contents.h:34:43: error: ?class v8::ArrayBuffer? has no member named ?GetContents?; did you mean ?IsContext??
         data   = static_cast<char*>(buffer->GetContents().Data()) + byte_offset;
                                             ^~~~~~~~~~~
                                             IsContext
  In file included from ../src/neon.cc:10:0:
  ../src/neon_task.h: In member function ?void neon::Task::complete()?:
  ../src/neon_task.h:62:70: warning: ?v8::Local<v8::Value> node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)? is deprecated: Use MakeCallback(..., async_context) [-Wdeprecated-declarations]
       node::MakeCallback(isolate_, context->Global(), callback, 2, argv);
                                                                        ^
  In file included from ../node_modules/nan/nan.h:54:0,
                   from ../src/neon.cc:2:
  /home/garrett/.electron-gyp/13.1.0/include/node/node.h:192:50: note: declared here
                   NODE_EXTERN v8::Local<v8::Value> MakeCallback(
                                                    ^
  /home/garrett/.electron-gyp/13.1.0/include/node/node.h:108:42: note: in definition of macro ?NODE_DEPRECATED?
       __attribute__((deprecated(message))) declarator
                                            ^~~~~~~~~~
  ../src/neon.cc: In function ?size_t Neon_ArrayBuffer_Data(void**, v8::Local<v8::ArrayBuffer>)?:
  ../src/neon.cc:216:20: error: ?Contents? is not a member of ?v8::ArrayBuffer?
     v8::ArrayBuffer::Contents contents = buffer->GetContents();
                      ^~~~~~~~
  ../src/neon.cc:217:15: error: ?contents? was not declared in this scope
     *base_out = contents.Data();
                 ^~~~~~~~
  ../src/neon.cc:217:15: note: suggested alternative: ?hostent?
     *base_out = contents.Data();
                 ^~~~~~~~
                 hostent
  ../src/neon.cc: In function ?void Neon_Class_SetClassMap(v8::Isolate*, void*, Neon_DropCallback)?:
  ../src/neon.cc:328:41: warning: ?void node::AtExit(void (*)(void*), void*)? is deprecated: Use the three-argument variant of AtExit() or AddEnvironmentCleanupHook() [-Wdeprecated-declarations]
     node::AtExit(cleanup_class_map, holder);
                                           ^
  In file included from ../node_modules/nan/nan.h:54:0,
                   from ../src/neon.cc:2:
  /home/garrett/.electron-gyp/13.1.0/include/node/node.h:866:22: note: declared here
       NODE_EXTERN void AtExit(void (*cb)(void* arg), void* arg = nullptr));
                        ^
  /home/garrett/.electron-gyp/13.1.0/include/node/node.h:108:42: note: in definition of macro ?NODE_DEPRECATED?
       __attribute__((deprecated(message))) declarator
                                            ^~~~~~~~~~
  In file included from ../src/neon.cc:8:0:
  ../src/neon_string.h: In member function ?v8::Local<v8::String> neon::Slice::ToJsString(v8::Isolate*, const char*)?:
  ../src/neon_string.h:28:18: warning: ignoring return value of ?bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::String; T = v8::String]?, declared with attribute warn_unused_result [-Wunused-result]
       maybe.ToLocal(&result);
       ~~~~~~~~~~~~~^~~~~~~~~
  make: *** [Release/obj.target/neon/src/neon.o] Error 1
  gyp ERR! build error 
  gyp ERR! stack Error: `make` failed with exit code: 2
  gyp ERR! stack     at ChildProcess.onExit (/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/node_modules/node-gyp/lib/build.js:258:23)
  gyp ERR! stack     at ChildProcess.emit (node:events:369:20)
  gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
  gyp ERR! System Linux 4.9.140+
  gyp ERR! command "/usr/bin/node" "/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/node_modules/.bin/node-gyp" "build"
  gyp ERR! cwd /home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native
  gyp ERR! node -v v15.14.0
  gyp ERR! node-gyp -v v3.6.2
  gyp ERR! not ok 

  error occurred: Command "ar" "crs" "/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/libneon.a" "/home/garrett/GDLauncher/node_modules/murmur2-calculator/native/target/release/build/neon-sys-8b60283ae9b6e8be/out/native/build/Release/obj.target/neon/src/neon.o" with args "ar" did not execute successfully (status code exit code: 1).

neon ERR! cargo build failed

Error: cargo build failed
    at Target.<anonymous> (/home/garrett/GDLauncher/node_modules/neon-cli/lib/target.js:98:27)
    at Generator.next (<anonymous>)
    at fulfilled (/home/garrett/GDLauncher/node_modules/neon-cli/lib/target.js:24:58)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)
Installation failed.
/home/garrett/GDLauncher/node_modules/electron-build-env/index.js:8
  var err = new Error(msg);
            ^

Error: electron-build-env error
    at error (/home/garrett/GDLauncher/node_modules/electron-build-env/index.js:8:13)
    at ChildProcess.<anonymous> (/home/garrett/GDLauncher/node_modules/electron-build-env/index.js:117:16)
    at ChildProcess.emit (node:events:369:20)
    at maybeClose (node:internal/child_process:1067:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5) {
  cmd: 'neon',
  args: [ 'build', 'murmur2-calculator', '--release' ],
  opts: {
    stdio: 'inherit',
    env: {
      LESSOPEN: '| /usr/bin/lesspipe %s',
      USER: 'garrett',
      LANGUAGE: 'en_CA:en',
      npm_config_user_agent: 'npm/7.13.0 node/v15.14.0 linux arm64 workspaces/false',
      TEXTDOMAIN: 'im-config',
      XDG_SEAT: 'seat0',
      SSH_AGENT_PID: '6642',
      XDG_SESSION_TYPE: 'x11',
      npm_node_execpath: '/usr/bin/node',
      LD_LIBRARY_PATH: '/usr/local/cuda-10.0/lib64',
      SHLVL: '1',
      RELEASE_TESTING: 'true',
      npm_config_noproxy: '',
      QT4_IM_MODULE: 'xim',
      HOME: '/home/garrett',
      DESKTOP_SESSION: 'budgie-desktop',
      npm_package_json: '/home/garrett/GDLauncher/package.json',
      QT_STYLE_OVERRIDE: '',
      npm_package_engines_node: '>=14.16.0',
      GTK_MODULES: 'gail:atk-bridge',
      MANAGERPID: '6090',
      npm_config_userconfig: '/home/garrett/.npmrc',
      DBUS_STARTER_BUS_TYPE: 'session',
      DBUS_SESSION_BUS_ADDRESS: 'unix:path=/run/user/1000/bus,guid=e6703ad85e817fdb8f8c83e460bd4097',
      npm_config_engine_strict: 'true',
      COLORTERM: 'truecolor',
      COLOR: '1',
      npm_config_metrics_registry: 'https://registry.npmjs.org/',
      QT_QPA_PLATFORMTHEME: 'gtk2',
      IM_CONFIG_PHASE: '2',
      LOGNAME: 'garrett',
      GTK_IM_MODULE: 'ibus',
      JOURNAL_STREAM: '8:22894',
      _: '/usr/bin/npm',
      npm_config_prefix: '/usr',
      USERNAME: 'garrett',
      XDG_SESSION_ID: '1',
      TERM: 'xterm-256color',
      npm_config_cache: '/home/garrett/.npm',
      GNOME_DESKTOP_SESSION_ID: 'this-is-deprecated',
      WINDOWPATH: '1',
      npm_config_node_gyp: '/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js',
      PATH: '/home/garrett/GDLauncher/node_modules/.bin:/home/garrett/node_modules/.bin:/home/node_modules/.bin:/node_modules/.bin:/usr/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin:/home/garrett/GDLauncher/node_modules/.bin:/home/garrett/node_modules/.bin:/home/node_modules/.bin:/node_modules/.bin:/usr/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin:/usr/local/cuda-10.0/bin:/home/garrett/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/garrett/.local/bin',
      INVOCATION_ID: 'f90288d9a9b148548509f1cb78848439',
      SESSION_MANAGER: 'local/garrett-usb:@/tmp/.ICE-unix/6467,unix/garrett-usb:/tmp/.ICE-unix/6467',
      NODE: '/usr/bin/node',
      npm_package_name: 'gdlauncher',
      XDG_MENU_PREFIX: 'gnome-',
      GNOME_TERMINAL_SCREEN: '/org/gnome/Terminal/screen/6f648233_4be2_435a_881b_48ed6be0fe71',
      XDG_RUNTIME_DIR: '/run/user/1000',
      DISPLAY: ':0',
      ZEITGEIST_DATA_PATH: '/home/garrett/.local/share/zeitgeist',
      LANG: 'en_CA.UTF-8',
      XDG_CURRENT_DESKTOP: 'Budgie:GNOME',
      LS_COLORS: 'rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:',
      XDG_SESSION_DESKTOP: 'budgie-desktop',
      XMODIFIERS: '@im=ibus',
      GNOME_TERMINAL_SERVICE: ':1.98',
      XAUTHORITY: '/run/user/1000/gdm/Xauthority',
      npm_lifecycle_script: 'node ./scripts/buildNativeDeps.js',
      SSH_AUTH_SOCK: '/run/user/1000/keyring/ssh',
      SHELL: '/bin/bash',
      npm_package_version: '1.1.8',
      npm_lifecycle_event: 'rebuild',
      QT_ACCESSIBILITY: '1',
      GDMSESSION: 'budgie-desktop',
      LESSCLOSE: '/usr/bin/lesspipe %s %s',
      TEXTDOMAINDIR: '/usr/share/locale/',
      GPG_AGENT_INFO: '/run/user/1000/gnupg/S.gpg-agent:0:1',
      XDG_VTNR: '1',
      QT_IM_MODULE: 'ibus',
      npm_config_globalconfig: '/usr/etc/npmrc',
      npm_config_init_module: '/home/garrett/.npm-init.js',
      PWD: '/home/garrett/GDLauncher',
      npm_execpath: '/usr/lib/node_modules/npm/bin/npm-cli.js',
      CLUTTER_IM_MODULE: 'xim',
      XDG_DATA_DIRS: '/usr/share/budgie-desktop:/home/garrett/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop',
      DBUS_STARTER_ADDRESS: 'unix:path=/run/user/1000/bus,guid=e6703ad85e817fdb8f8c83e460bd4097',
      XDG_CONFIG_DIRS: '/etc/xdg/xdg-budgie-desktop:/etc/xdg',
      npm_command: 'run-script',
      VTE_VERSION: '5202',
      INIT_CWD: '/home/garrett/GDLauncher',
      EDITOR: 'vi',
      npm_config_target: '13.1.0',
      npm_config_arch: 'arm64',
      npm_config_target_arch: 'arm64',
      npm_config_disturl: 'https://atom.io/download/electron',
      npm_config_runtime: 'electron',
      npm_config_build_from_source: true,
      npm_config_devdir: '/home/garrett/.electron-gyp'
    },
    shell: true
  },
  stderr: ''
}
npm ERR! code 1
npm ERR! path /home/garrett/GDLauncher
npm ERR! command failed
npm ERR! command sh -c npm run rebuild

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/garrett/.npm/_logs/2021-06-07T04_04_12_071Z-debug.log
theofficialgman commented 3 years ago

@killpowa I'd appreciate your input on this, I realize you are probably very busy and this is low priority as arm64 isn't officially supported by mojang even now. https://github.com/gorilla-devs/GDLauncher/issues/727#issuecomment-854377002 all I need help with is these two depends and then I should be able to launch and see if other issues arise

nicholasaiello commented 3 years ago

@theofficialgman try this POC branch, https://github.com/nicholasaiello/GDLauncher/tree/arm64-updates

i rebuilt those two dependencies in Raspberry Pi OS (64-bit), and made other changes to the build scripts in order to support arm64. the launcher runs fine, and i'm able to play all versions, pre 1.17.x

here's how i built and ran the launcher (after npm i)

$ npm run release:setup
$ ./deploy/GDLauncher-linux-setup.AppImage

assuming that java is setup, and you have lwjgl3arm64, then you should be good to go

cobalt2727 commented 3 years ago

So I've decided to melt my raspberry pi tonight by testing this out and I can confirm it builds (Ubuntu MATE 21.04, NodeSource LTS 14.something, Pi 4B 8GB)

I've got openjdk 16 installed so I'll give 1.17 a go and see if it launches in a moment

Screenshot at 2021-07-26 00-37-02

nicholasaiello commented 3 years ago

@cobalt2727 thanks for trying it. any luck running 1.17.x? the issues that i ran into (re: 1.17.x releases) seemed to be caused by my java configuration, and AFAIK i'm using openjdk 11... i ran this script (found it on the Pi forums), in order to setup my java environment, and lwjgl libs: https://github.com/mikehooper/Minecraft/raw/main/setupMC.sh. otherwise, the launcher itself appeared to be working fine

theofficialgman commented 3 years ago

minecraft 1.17.x requires java 16 now, so openjdk 11 just won't work I have a nintendo switch running linux, will test on this later today/tomorrow Since your branch itself doesn't detail how to compile those couple of binaries, I'd really appreciate you documenting how you did so.

cobalt2727 commented 3 years ago

-fresh purge and reinstall of NodeJS from nodesource LTS because I hate npm packages and everything was broken until I did a fresh start

-git clone; cd GDLauncher

-npm i

-npm run dev

cobalt2727 commented 3 years ago

@cobalt2727 thanks for trying it. any luck running 1.17.x? the issues that i ran into (re: 1.17.x releases) seemed to be caused by my java configuration, and AFAIK i'm using openjdk 11... i ran this script (found it on the Pi forums), in order to setup my java environment, and lwjgl libs: https://github.com/mikehooper/Minecraft/raw/main/setupMC.sh. otherwise, the launcher itself appeared to be working fine

I pulled from that script to set up lwjgl as well on my pi, GDLauncher didn't seem to open my 1.17 Fabric modpack instance despite me setting my java to Ubuntu's openJDK 16 manually... I only tried 1.17 before I signed off for the night, but I can try 1.16 this evening

theofficialgman commented 3 years ago

@nicholasaiello for one, you can't just setup your lwjgl binaries using that script and expect it to work you need to tell gdlauncher the location of them so that they will work

I get the same error as cobalt when trying to open the command window to view the logs i attempted to pass a custom library folder location to gdlauncher but it doesn't seem to do anything -Djava.library.path=

cobalt2727 commented 3 years ago

I don't think I properly set up lwjgl, come to think of it. I'll make sure that's working next time I test

theofficialgman commented 3 years ago

you can view the log inside the instances folder in gdlauncher_next unfortunatly regardless of what I do with -Djava.library.path= or -Dorg.lwjgl.librarypath I still get the error saying that lwjgl failed to load libraries

[09:59:37] [Render thread/INFO]: [STDERR]: [LWJGL] Failed to load a library. Possible solutions:
    a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
    b) Add the JAR that contains the shared library to the classpath.
[09:59:37] [Render thread/INFO]: [STDERR]: [LWJGL] Enable debug mode with -Dorg.lwjgl.util.Debug=true for better diagnostics.
[09:59:37] [Render thread/INFO]: [STDERR]: [LWJGL] Enable the SharedLibraryLoader debug mode with -Dorg.lwjgl.util.DebugLoader=true for better diagnostics.

I imagine that gdlauncher is dropping those commands from the jvm arguements I guess... just like the other launchers

nicholasaiello commented 3 years ago

@nicholasaiello for one, you can't just setup your lwjgl binaries using that script and expect it to work you need to tell gdlauncher the location of them so that they will work

I get the same error as cobalt when trying to open the command window to view the logs i attempted to pass a custom library folder location to gdlauncher but it doesn't seem to do anything -Djava.library.path=

no expectations for the script to handle everything. just stating what i used to install those binaries. configuring the launcher is another thing. in order to point to said binaries, i added the following to the launcher's java args:

-Dorg.lwjgl.librarypath=/home/pi/lwjgl3arm64

here's an image of the Pi running MC Vanilla 1.16.5, from this past Sunday. image

back to the original issue, if people are able to build on arm64 platforms, that's a positive. any trouble after that, mainly around configuration, could be solved with additional documentation. i could compile the commands that i used in to a gist if the maintainers think it'd be useful. @Ladvace @killpowa thoughts?

cobalt2727 commented 3 years ago

I know some distros don't have Java 16 available as the default, or even available in the normal repositories yet (looking at you, Debian), so it could be nice if GDLauncher shipped with aarch64/armhf Java binaries. Could probably just borrow them from AdoptOpenJDK or something, I'm not familiar with any licensing issues there

theofficialgman commented 3 years ago

oh wait.. do all the .jar files have to be in one folder when you load with -Dorg.lwjgl.librarypath? I was using the MultiMC standard where the libraries are sorted into subfolders based on type and version.. I'll need to try with all the jar files in one folder later today. hopefully thats my problem I can also just try the pi binaries as well.. not sure what those were compiled against but they might work as well currently I just get binares from luckchambers or JJTech0130

theofficialgman commented 3 years ago

@nicholasaiello I can confirm it was the formatting of the folder and binary file type that it didn't like. I was able to load minecraft with the binaries from mikehooper even though I got a lot of these errors in the log 

[17:08:23] [Render thread/INFO]: [STDERR]: [LWJGL] [ERROR] Incompatible Java and native library versions detected.
Possible reasons:
    a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version.
    b) The classpath contains jar files of an older LWJGL version.
Possible solutions:
    a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make
       sure the folder it points to contains the shared libraries of the correct LWJGL version.
    b) Check the classpath and make sure to only have jar files of the same LWJGL version in it.

I'm not quite sure how all the file types are interlinked, because my MultiMC5 meta repo pulls only .jar files, while the code you linked (mikehooper) has both .so and .jar files, and then we have lukechambers mcswitchtools which only supplies .so files

the latter two, mikehooper and luke chambers expect you to load the binaries with -Dorg.lwjgl.librarypath multimc5 has its own library loading mechanism

theofficialgman commented 3 years ago

also I can confirm minecraft 1.17.1 works just fine with a java 16 binary selected I'm using the binaries found here https://gitlab.com/devluke/mcswitchtools/-/tree/master/MCSwitchTools/natives/3 there are lwjgl3 and 2 versions for arm64 and using them with the -Dorg.lwjgl.librarypath option

theofficialgman commented 3 years ago

@nicholasaiello would you mind walking through how you were able to build the murmur2-arm64.node and nsfw-arm64.node binaries? so its documented and so I can repeat in the future as needed

cobalt2727 commented 3 years ago

seconded

Eskaan commented 3 years ago

So @theofficialgman is it resolved? We also released a new release whit Java 16 support, that could cause trouble from what I read here

theofficialgman commented 3 years ago

@Code-Ac No this is not resolved. the official GDLauncher will never build on arm64 until the changes are implemented from the @nicholasaiello fork/branch in a universal way to allow arm64 and x86_64 building. currently the gdlauncher contains x86_64 binaries for a couple of libraries which will cause any other architecture type to fail building among other small issues

Eskaan commented 3 years ago

Okay, thanks

nicholasaiello commented 3 years ago

@nicholasaiello would you mind walking through how you were able to build the murmur2-arm64.node and nsfw-arm64.node binaries? so its documented and so I can repeat in the future as needed

apologies for the late response, all. i would not mind, and will try to get some simple instructions together in a gist (or two) — just need to pull the commands from that particular RPi4's SSD. nsfw built just fine w/ node-gyp (using nvm to run the latest LTS Node.js 14.17.x). there were some build issues w/ murmur2 that required small changes... a one-line change to the header file, and maybe a couple changes to the sconstruct file (need to check the SSD) — there's probably a better way to do this, though. i've had limited bandwidth lately, so will need a few days to turn this around

blarfoon commented 3 years ago

Guys YOU ARE INSANE! Dropping ARM64 support (and possibly x32) was one of my goals for the future. Please contact me on discord I'd love to collaborate with you on this!

JJTech0130 commented 2 years ago

@nicholasaiello I can confirm it was the formatting of the folder and binary file type that it didn't like. I was able to load minecraft with the binaries from mikehooper even though I got a lot of these errors in the log

[17:08:23] [Render thread/INFO]: [STDERR]: [LWJGL] [ERROR] Incompatible Java and native library versions detected.
Possible reasons:
  a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version.
  b) The classpath contains jar files of an older LWJGL version.
Possible solutions:
  a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make
     sure the folder it points to contains the shared libraries of the correct LWJGL version.
  b) Check the classpath and make sure to only have jar files of the same LWJGL version in it.

I'm not quite sure how all the file types are interlinked, because my MultiMC5 meta repo pulls only .jar files, while the code you linked (mikehooper) has both .so and .jar files, and then we have lukechambers mcswitchtools which only supplies .so files

the latter two, mikehooper and luke chambers expect you to load the binaries with -Dorg.lwjgl.librarypath multimc5 has its own library loading mechanism

@theofficialgman IIRC the .jars are simply zips containing the .so ... I have a script to generate it around here somewhere...

theofficialgman commented 2 years ago

yes I know.... I've made the .jar files myself already (you can see them on my github) the problem is there its not trivial to get gdlauncher to automate loading replacement jars (without asking the user which version of lwjgl is really needed). there isn't any scripting support within gdlauncher to hotpatch in separate libraries, and use java arguments isn't a workable solution either since it would need the change per instance/version of minecraft

theofficialgman commented 2 years ago

@JJTech0130 your response was to stupid past me from months ago. I didn't understand at the time but am much better educated and knowledgeable now

JJTech0130 commented 2 years ago

Ah. Do you know of any alternative launchers that actually work on the pi (other than MMC)? I'm looking for a friend who wants something more modern and user friendly than MMC)-- that's how I stumbled upon this issue 😆

theofficialgman commented 2 years ago

the lunar client decompilation project from pi-labs is an OK solution if you don't care about older minecraft versions... but its more a hack than anything and I doubt it will be kept up to date very well

otherwise thats it... though MMC isn't THAT bad (I know we are a bit biased but thats what I would recommend)

JJTech0130 commented 2 years ago

Ok... I use it myself but the older-style ui scared my friend away... will try and convince them :)

theofficialgman commented 2 years ago 
[17:08:23] [Render thread/INFO]: [STDERR]: [LWJGL] [ERROR] Incompatible Java and native library versions detected.
Possible reasons:
    a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version.
    b) The classpath contains jar files of an older LWJGL version.
Possible solutions:
    a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make
       sure the folder it points to contains the shared libraries of the correct LWJGL version.
    b) Check the classpath and make sure to only have jar files of the same LWJGL version in it.

fyi: these errors that I reported before come from the non-native .jar files still being used from the minecraft repo while the natives I replaced from my own binaries (which have a few commit differences in order to compile on arm64 and thus they aren't fully compatible). You need to load both the custom natives and non-natives in order to avoid that (which is what the MultiMC launcher does)

JJTech0130 commented 2 years ago

Wait... So LWJGL is checking for compatibility, and deeming them incompatible, so we hot-patch it after the check?

JJTech0130 commented 2 years ago

By non-native do you mean 1) Natives for x86 on aarch64 or 2) Java files not compiled for any specific arch?

theofficialgman commented 2 years ago

Wait... So LWJGL is checking for compatibility, and deeming them incompatible, so we hot-patch it after the check?

by non-native I mean the java files not compiled for any specific arch

no what was happening in my error report was we let gdlauncher download the jars (natives and non-natives) and then fail to launch minecraft (since it downloads x86_64 natives) then I added just the arm64 compiled .so files to a directory and make gdlauncher use those with the -Djava.library.path= but still keeping the other non-native jars from minecraft itself

that produced the errors because the non-natives jars from minecraft are "slightly" different from the ones that I compiled

JJTech0130 commented 2 years ago

Ah ok, so can you just recompile the non-natives?

theofficialgman commented 2 years ago

yes I have all the non-natives recompiled in addition to the natives everything is here: https://github.com/theofficialgman/lwjgl3-binaries-arm64 there is a branch for each lwjgl version

JJTech0130 commented 2 years ago

so does that fix the error?

theofficialgman commented 2 years ago

idk... I was trying right now but gdlauncher seems to hate me and won't launch minecraft at all... and this is all I get in my log

[19:24:22] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'

[19:24:24] [Render thread/INFO]: Setting user: myusername replaced for privacy
theofficialgman commented 2 years ago

so does that fix the error?

so... I can't actually even change out the non-natives in gdlauncher because that would require adding them to the java classpath... and that seems to be generated when you click the launch button and nowhere else before that

and I can't outright replace/specify the classpath myself because then none of minecrafts own jar files (the game itself) get loaded, lol

so I think its a "can't fix" based on how gdlauncher is written