4JX / L5P-Keyboard-RGB

Cross platform software to control the RGB/lighting of the 4 zone keyboard included in the 2020, 2021, 2022 and 2023 lineup of the Lenovo Legion laptops. Works on Windows and Linux.
GNU General Public License v3.0
308 stars 39 forks source link

Unable to compile with cargo build #17

Closed gnomiik closed 2 years ago

gnomiik commented 3 years ago

When doing cargo build it complains about

"error: failed to run custom build command for `scrap v0.5.0"

Here is the full log

RUST_BACKTRACE=full cargo build

Compiling fltk-sys v1.1.16 Compiling scrap v0.5.0 (/media/X/t/L5P-Keyboard-RGB-0.7.0/libs/scrap) error: failed to run custom build command for scrap v0.5.0 (/media/X/t/L5P-Keyboard-RGB-0.7.0/libs/scrap)

Caused by: process didn't exit successfully: /media/X/t/L5P-Keyboard-RGB-0.7.0/target/debug/build/scrap-e71d258a2e2dc590/build-script-build (exit code: 101) --- stderr thread 'main' panicked at 'called Result::unwrap() on an Err value: NotPresent', libs/scrap/build.rs:7:63 stack backtrace: 0: 0x5566196b6781 - ::fmt::hc07c9cd6473c184f 1: 0x5566196e15ec - core::fmt::write::hd5abae825e92a210 2: 0x5566196c2187 - std::io::Write::write_fmt::h3f63b42f66032676 3: 0x5566196bdce2 - std::panicking::default_hook::{{closure}}::h9451e4f30330b478 4: 0x5566196bd9ab - std::panicking::default_hook::hccf5200ac295eadd 5: 0x5566196be31a - std::panicking::rust_panic_with_hook::h8d53767150680421 6: 0x5566196bdefb - rust_begin_unwind 7: 0x5566196ee281 - core::panicking::panic_fmt::h59908d1ffbada4a3 8: 0x5566196ee313 - core::result::unwrap_failed::h90156c5ceff9b971 9: 0x5566190a2eb7 - core::result::Result<T,E>::unwrap::h3a90bebaed428072 at /tmp/rustc-1.46.0-src/src/libcore/result.rs:1005 10: 0x55661909d95d - build_script_build::find_package::hd12a8f01cc37db73 at libs/scrap/build.rs:7 11: 0x55661909fa5b - build_script_build::main::h32c56f700991bd73 at libs/scrap/build.rs:86 12: 0x5566190a2b5b - std::rt::lang_start::{{closure}}::h2d70ff4dcd9d85d6 at /tmp/rustc-1.46.0-src/src/libstd/rt.rs:67 13: 0x5566196bbb45 - std::rt::lang_start_internal::h50104ee6cf97d478 14: 0x5566190a2b34 - std::rt::lang_start::h572ea5d604fdc3d4 at /tmp/rustc-1.46.0-src/src/libstd/rt.rs:67 15: 0x55661909fbda - main 16: 0x7f58cf3697d0 - __libc_start_main 17: 0x55661909d379 - _start at ../sysdeps/x86_64/start.S:108 18: 0x0 - warning: build failed, waiting for other jobs to finish... error: build failed

4JX commented 2 years ago

You'll need a VCPKG_INSTALLATION_ROOT environment variable pointing to a valid VCPKG folder with a VCPKG binary built.

Do check the workflows for the dependencies you'll need to install and the general build process for each OS.

gnomiik commented 2 years ago

Isn't VCPKG for windows? I am trying to compile in linux

gnomiik commented 2 years ago

Could you please just make an AppImage, then I could run the binary and no need to compile. If this is possible of course. Thanks in advance!

4JX commented 2 years ago

Its still needed on linux for a few dependencies, see: https://github.com/4JX/L5P-Keyboard-RGB/blob/31b40067b24defda0bc77425026fce7c5fd449be/.github/workflows/release-rust.yml#L50

Prebuilt binaries are already uploaded via actions for each commit, but for the current version you can download it from the releases: https://github.com/4JX/L5P-Keyboard-RGB/releases/download/v0.7.0/l5p-kb-rgb-linux.zip

Needs to be marked as executable and run as root.

gnomiik commented 2 years ago

I probably should have clarified why i wanted a static executable because my glibc is too old. Is it possible to make a static executable? Thanks.

Output when I run it.

./l5p-kb-rgb ./l5p-kb-rgb: /lib64/libm.so.6: version GLIBC_2.27' not found (required by ./l5p-kb-rgb) ./l5p-kb-rgb: /lib64/libm.so.6: versionGLIBC_2.29' not found (required by ./l5p-kb-rgb) ./l5p-kb-rgb: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ./l5p-kb-rgb)

4JX commented 2 years ago

I probably should have clarified why i wanted a static executable because my glibc is too old. Is it possible to make a static executable? Thanks.

Output when I run it.

./l5p-kb-rgb ./l5p-kb-rgb: /lib64/libm.so.6: version GLIBC_2.27' not found (required by ./l5p-kb-rgb) ./l5p-kb-rgb: /lib64/libm.so.6: versionGLIBC_2.29' not found (required by ./l5p-kb-rgb) ./l5p-kb-rgb: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ./l5p-kb-rgb)

I don't have experience with creating statically linked apps, but after a few searches it seems as though apps packed as AppImages still rely on the system glibc by default. This seems to be able to fix that specific issue, however it currently errors out on my machine.

Another possibility would be to straight up compile against an older glibc in the github actions, though I first need to know your current version for that.

If you have resources about creating an AppImage with glibc that would be appreciated.

gnomiik commented 2 years ago

My glibc version is 2.23. It would be awesome to get it compiled on that version and older distro's will be well supported then. I don't know how to do AppImage with glibc, wish I could help with that though.Perhaps ld-linux can be used to load say new packaged glibc.

azubieta commented 2 years ago

@gnomiik if you're creating your AppImage using appimage-builder it will be embed by default.

4JX commented 2 years ago

Hey @gnomiik can you try compiling with cargo-make and see how that goes? There's a slight chance you'll need to manually find and install dependencies specific to your distro, but otherwise it should be automated enough.

As for the AppImage, currently waiting on https://github.com/AppImageCrafters/appimage-builder/issues/164. It doesn't seem like the github actions runners go to an old enough version of ubuntu for your specific GLIBC, so hopefully this works.

4JX commented 2 years ago

Closing due to inactivity

OrderlyUnicode commented 1 year ago

I know this has been closed for over a year, but I'm currently having the same issue and I'm running into the same issue and getting the same error regardless of whether I attempt to build via cargo-make or use vcpkg then regular cargo. I doubt this is a glibc issue, at least as far as versioning, because I'm running 2.37 and it still persists