Prebuilts for Linux are broken

[Djiit]

Since we merged the new build process (#258), we have Electron 9+ and node 12+ support, but the prebuilt are broken.

[ericwooley]

Might want to unpublish 0.7.0+ If that is going to break for people?

I was just trying to integrate iohooks and having issues, when I saw this issue pop up. If it helps anyone, here is here my config, and logs
node: 12.18.3
electron: 11.0.4
OS:

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

iohook package.json config

  "iohook": {
    "targets": [
      "node-72",
      "electron-85"
    ],
    "platforms": [
      "win32",
      "darwin",
      "linux"
    ],
    "arches": [
      "x64"
    ]
  },

npm rebuild output

this seems strange, It seems like it should download the node72 and electron85, but only downloads one of them

> iohook@0.7.1 install /home/ericwooley/tengable/node_modules/iohook
> node install.js

node 72 win32 x64
Downloading prebuild for platform: iohook-v0.7.1-node-v72-win32-x64
Downloading prebuild.tar.gz
[============================================>] 100.0% of 153.68 kB (153.68 kB/s)
Downloading prebuild.tar.gz
[============================================>] 100.0% of 26.18 kB (26.18 kB/s)
Downloading prebuild.tar.gz
[============================================>] 100.0% of 34.35 kB (34.35 kB/s)
Downloading prebuild.tar.gz
[============================================>] 100.0% of 153.61 kB (153.61 kB/s)
Downloading prebuild.tar.gz
[============================================>] 100.0% of 26.26 kB (26.26 kB/s)
Downloading prebuild.tar.gz
[============================================>] 100.0% of 34.37 kB (34.37 kB/s)

Logs from trying to require iohook in node:

➜ node          
Welcome to Node.js v12.18.3.
Type ".help" for more information.
> const iohook = require('iohook')
load_input_helper [1918]: Using XFree86 keyboard layout.
load_input_helper [1920]: XKB support is required to accurately determine keyboard characters!
nodeundefined
: symbol lookup error: /home/ericwooley/tengable/node_modules/iohook/builds/node-v72-linux-x64/build/Release/uiohook.so: undefined symbol: XGetXCBConnection

[marcelblum]

FWIW, latest Windows prebuilds do work fine - tested successfully on Win 10/Electron 11/iohook 0.7.1.

Mac 0.7.1 prebuilds fail with error dlopen([...]/iohook.node, 1): Library not loaded: @rpath/uiohook.dylib Referenced from: [...]/iohook.node Reason: image not found. Tested on macOS 10.13 and 11.0.

[marcelblum]

#269 fixes the Mac build issue as far as I can tell from my own testing on macOS 10.13 and 11.0.

Linux issue looks like a totally different one. That being said the same lines I changed in the Mac build defs in #269 appear to be broken/malformed in the Linux defs too but maybe loading libs on Linux is smarter than on Mac so this has no effect (e.g. on Linux the loader's path is automatically used to search for the requested library file by default without having to specify it in the rpath as on Mac). For reference in case someone who knows Linux better than I wants to take a look, the lines in question are

iohook/build_def/linux/uiohook.gyp

Line 21 in e51a869

"-Wl,-rpath,<!(node -e \"console.log('builds/' + process.env.gyp_iohook_runtime + '-v' + process.env.gyp_iohook_abi + '-' + process.env.gyp_iohook_platform + '-' + process.env.gyp_iohook_arch + '/build/Release')\")",

and

iohook/build_def/linux/binding.gyp

Line 22 in e51a869

"-Wl,-rpath,<!(node -e \"console.log('builds/' + process.env.gyp_iohook_runtime + '-v' + process.env.gyp_iohook_abi + '-' + process.env.gyp_iohook_platform + '-' + process.env.gyp_iohook_arch + '/build/Release')\")",

[ykhwong]

: symbol lookup error: /home/ericwooley/tengable/node_modules/iohook/builds/node-v72-linux-x64/build/Release/uiohook.so: undefined symbol: XGetXCBConnection

Linking with X11-xcb may be required for the undefined symbol XGetXCBConnection. #270 will fix the issue.

[Djiit]

@marcelblum I was able to reproduce on y macOS to. Merged and generating prebuilt now. @ykhwong Also merged your fix.

@ericwooley I'll unpublish these versions from NPM later today if it doesn't work.

[Djiit]

v0.7.2 fixes prebuilds for macos, thanks a lot @marcelblum

[lanye74]

Yeah, having new prebuilts will be super nice for those of us who don't bother with building it :)

[abhijit-hota]

If I don't want to use it in an Electron environment and only in a basic Node app, are there any available workarounds as of now?

[marcelblum]

@abhijit-hota current status AFAIK from my own testing and other users' comments:

• Windows latest iohook 0.7.2 - working in Electron through latest 11.x, working in Node up to v13.x, not working Node v14+
• Windows prev iohook 0.6.6 - working in Electron up to v8.x, not working Electron v9+, working in Node up to v14.x, no support for Node v15
• Mac latest iohook 0.7.2 - working in Electron through latest 11.x, working in Node through latest v15.x
• Mac prev iohook 0.6.6 - working in Electron up to v8.x, not working Electron v9+, working in Node up to v14.x, no support for Node v15
• Linux...? Someone fill in here please :) from other users comments seems latest iohook 0.7.2 is (like Windows) not working in Node v14+, but prev iohook 0.6.6 does work in Node through v14.x

If you really need Node v15 support you could try using the iohook 0.6.6 codebase (pre node-gyp) and manually building for that target, it might "just work".

[abhijit-hota]

Thanks for summarizing it @marcelblum . Windows environment checks out.
On Linux, as others have said:

• Linux (WSL Ubuntu 20.04)
• Windows 10
• Node 14.5.3 (also tested in Node 15.5.0)
• iohook 0.7.2

on_library_load [458]: XOpenDisplay failure!
load_input_helper [1918]: Using XFree86 keyboard layout.
load_input_helper [1920]: XKB support is required to accurately determine keyboard characters!
[1]    31701 segmentation fault  node index.js

[abhijit-hota]

⚠ Maybe not accurate. Need feedback. ⚠

Node Environment

	0.7.2		0.6.6
	Node 14+	Node 15+	Node 14+	Node 15+
Windows	❌[1]	❌	✔	❌
Mac	✔	✔	✔	❌
Linux[2]	❌	❌	❌	❌

[1] Suported upto Node 13.x
[2] Tested in WSL. See @ykhwong 's comments below.

Electron

	0.7.2		0.6.6
	Electron 8+	Electron 9+	Electron 8+	Electron 9+
Windows	✔	✔	✔	❌
Mac	✔	✔	✔	❌
Linux	❔	❔	❔	❔

[ykhwong]

Same environment but iohook 0.6.6:

internal/modules/cjs/loader.js:1122
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1122:18)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/home/abhijit/my-project-name/node_modules/iohook/index.js:10:21)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)

It does not seem to have either libxkbcommon-x11-0 or libxkbcommon-x11-dev installed. Try again after installing it.
sudo apt-get install -y libxkbcommon-x11-0

[abhijit-hota]

@ykhwong Oh snap. I did install it but I get this error again:

on_library_load [456]: XOpenDisplay failure!
load_input_helper [1907]: XkbGetKeyboard failed to locate a valid keyboard!
[1]    6149 segmentation fault  node index.js

[ykhwong]

@ykhwong Oh snap. I did install it but I get this error again:

on_library_load [456]: XOpenDisplay failure!
load_input_helper [1907]: XkbGetKeyboard failed to locate a valid keyboard!
[1]    6149 segmentation fault  node index.js

X11 is a dependency of the Linux prebuilds, but WSL1 and WSL2 both do not have an X11 server by default. You can install a discrete X11 server software such as VcXsrv for Windows. Start the server on Windows and add the following line to $HOME/.bashrc:

export DISPLAY=:0.0

After restarting the terminal, the XOpenDisplay failure message will disappear.

Alternatively, for a non-production/testing purpose, a fake X11 called xvfb can be set up by typing sudo apt-get install -y xvfb
Type the following commands and try again.

Xvfb :99 &
export DISPLAY=:99

[abhijit-hota]

@ykhwong Thank you for the detailed steps. However, can I expect 0.7.2+ versions to support WSL2 without any manual tinkering like this?

P.S. I really don't know how it all works so pardon me for stupid questions if any.

[ykhwong]

@abhijit-hota The iohook depends on libuiohook that requires X11 for the Linux platform by nature. It is not a WSL-specific issue. You may encounter the situation on any non-GUI based Linux system without a proper X11 server configuration.

Without X11 or the like, I have no idea how we can handle keyboard and mouse events via native hooks inside and outside your application.

[abhijit-hota]

@abhijit-hota The iohook depends on libuiohook that requires X11 for the Linux platform by nature. It is not a WSL-specific issue. You may encounter the situation on any non-GUI based Linux system without a proper X11 server configuration.

Without X11 or the like, I have no idea how we can handle keyboard and mouse events via native hooks inside and outside your application.

Oh I see.
Thanks a lot for the explanation. =)

[Djiit]

Hey @ykhwong , thanks for the explanation. Maybe we should just make it obvious in the README that it requires this on Linux.

[abhijit-hota]

Hey @ykhwong , thanks for the explanation. Maybe we should just make it obvious in the README that it requires this on Linux.

Yes. As there are others who face the same issue. (#249 )

[ykhwong]

Hey @ykhwong , thanks for the explanation. Maybe we should just make it obvious in the README that it requires this on Linux.

I agree. I hope you find the information useful. Thanks. :)

[harshit99-cyber]

stil iohook is broken?

[harshit99-cyber]

for linux

[renzner]

I'm still having issues with Ubuntu 18.04.5

[catdad]

I assumed that after #279 was merged, we were really just waiting for a new release, since the binaries need to be rebuilt. But 0.9.0 was recently released and those binaries appear to also result in the same error. I am thinking this issue is not fixed.

[NINNiT]

Same on my side using Arch (and X11)

[catdad]

I debugged and look like Xtst needs to be linked as well. I created some prebuilds which you can manually download from the artifacts of this build. These work for me, but it would be great to hear from others as well.

I created #314 to update the bindings with this change.

[renzner]

@catdad
Awesome! it worked on ubuntu 18.04. Big thanks :)

[NINNiT]

@catdad Thanks, it worked for me too :)

[metal450]

Just updated Node from 10.x to 14.x, & a previously working app broke with the "XKB support is required to accurately determine keyboard characters" error - it looks like a fix is in the works, but as the latest version on npm is still non-functional, I tried extracting the binaries in @catdad's prebuilds.zip/iohook-v0.9.0-node-v83-linux-x64.tar.gz into node_modules/iohook/node-v83-linux-x64. Unfortunately, the segmentation fault persists. It sounds like some were able to get this going, if you could provide any tips I'd greatly appreciate. I thought just extracting catdad's binaries to the mentioned paths would work, but it doesn't seem to in my case.

[AbhijithBn]

Still seeing the same error as mentioned above in Linux

[rodrigograca31]

Same here!

Node: v14.15.0
Linux Mint (not WSL crap 😂)

load_input_helper [1918]: Using XFree86 keyboard layout.
load_input_helper [1920]: XKB support is required to accurately determine keyboard characters!
[1]    123230 segmentation fault  sudo node hardware/keyboard.js

[ghost]

Guess what's changed... absolutely nothing. Last time I tried this was April and it is STILL broken.

load_input_helper [1920]: XKB support is required to accurately determine keyboard characters!

I guess iohook will STILL be left out of my project. /shrug

[metal450]

yup, likewise...

[rodrigograca31]

Yeah my project is on hold because I cant capture keypresses with either this package or others....