279 linked xkbcommon-x11 and X11-xcb, but that wasn't all that was missing for Linux builds. The error after that PR resulted in undefined symbol: XRecordQueryVersion, which appears to be part of Xtst... which just so happens to be one of the packages installed in order to build libuiohook. Linking it solves the problem I had on Linux and allows prebuilds to work correctly.
Motivation and Context
This fixes #268 (says closed, but the issue actually persists even in 0.9.0)
How Has This Been Tested?
I manually tested one node and one electron prebuilt on a fresh clean Linux 20.04 Desktop install. With 0.9.0, an error is thrown for undefined symbol: XRecordQueryVersion followed by an exit with code 127, and with this PR, the lib is loaded correctly and seems to work.
Screenshots (if appropriate):
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
Description
279 linked xkbcommon-x11 and X11-xcb, but that wasn't all that was missing for Linux builds. The error after that PR resulted in
undefined symbol: XRecordQueryVersion
, which appears to be part of Xtst... which just so happens to be one of the packages installed in order to build libuiohook. Linking it solves the problem I had on Linux and allows prebuilds to work correctly.Motivation and Context
This fixes #268 (says closed, but the issue actually persists even in 0.9.0)
How Has This Been Tested?
I manually tested one node and one electron prebuilt on a fresh clean Linux 20.04 Desktop install. With 0.9.0, an error is thrown for
undefined symbol: XRecordQueryVersion
followed by an exit with code 127, and with this PR, the lib is loaded correctly and seems to work.Screenshots (if appropriate):
Types of changes
Checklist: