GPU build fails to compile: boost/compute/detail/sha1.hpp incompatible with modern Boost (unsigned int[5] vs unsigned char[20] digest signature)

Building the GPU-enabled version of LightGBM (-DUSE_GPU=ON / --use-gpu) fails to compile when linking against a modern system/vendor-provided Boost (Boost ≥ 1.86), because LightGBM's vendored copy of Boost.Compute (external_libs/compute/include/boost/compute/detail/sha1.hpp) calls boost::uuids::detail::sha1::get_digest() using an outdated function signature.

Boost changed the sha1::get_digest() signature as part of a security/correctness fix to the SHA-1 implementation, changing the digest type from a 5-element unsigned int[5] array to a 20-element unsigned char[20] array. LightGBM's vendored boost/compute/detail/sha1.hpp still calls it using the old signature, so any build against Boost ≥ 1.86 fails.

This affects any platform/toolchain using a modern Boost — I hit it specifically building the R-package with --use-gpu --use-mingw on Windows using both:

vcpkg's boost-compute port (Boost 1.85/1.86+) Rtools45's bundled MinGW-w64 Boost Both produce the identical error, confirming it's not toolchain-specific.

Environment LightGBM version: main branch, commit built on 2026-09-16 (R package version reported as 4.7.0.99) OS: Windows 11 (build with Fast Startup enabled, if relevant) R version: 4.6.1, x86_64 Toolchain: Rtools45 (MinGW-w64, GCC 14.2.0) Boost: Rtools45-bundled Boost (and separately reproduced with vcpkg's boost-compute:x64-mingw-static, Boost 1.85.0) OpenCL: NVIDIA CUDA Toolkit v12.8 (headers + import lib) GPU: NVIDIA GeForce RTX 3060 Laptop GPU, driver 32.0.16.1692 Steps to reproduce

git clone --recursive https://github.com/lightgbm-org/LightGBM
cd LightGBM
Rscript build_r.R --use-gpu --use-mingw `
    --boost-root="<path-to-any-Boost->=1.86-install>" `
    --opencl-include-dir="<CUDA include dir>" `
    --opencl-library="<path>\OpenCL.lib"

Error

C:/.../lightgbm/src/external_libs/compute/include/boost/compute/detail/sha1.hpp:41:26:
error: cannot convert 'unsigned int [5]' to 'unsigned char (&)[20]'
   41 |             h.get_digest(digest);
      |                          ^~~~~~
      |                          |
      |                          unsigned int [5]

C:/.../include/boost/uuid/detail/sha1.hpp:179:43: note:
inline void sha1::get_digest(digest_type& digest)
                              ~~~~~~~~~~~~~^~~~~~

Build fails at data_parallel_tree_learner.cpp.obj with mingw32-make: *** Error 2.

Root cause

File: `external_libs/compute/include/boost/compute/detail/sha1.hpp`
        operator std::string() {
            unsigned int digest[5];
            h.get_digest(digest);

            std::ostringstream buf;
            for(int i = 0; i < 5; ++i)
                buf << std::hex << std::setfill('0') << std::setw(8) << digest[i];

            return buf.str();
        }

This assumes sha1::get_digest() takes a unsigned int[5]&. Modern Boost (≥1.86) defines it as void get_digest(unsigned char (&digest)[20]).

Suggested fix

Update the vendored file to match the modern Boost signature:
        operator std::string() {
            unsigned char digest[20];
            h.get_digest(digest);

            std::ostringstream buf;
            for(int i = 0; i < 20; ++i)
                buf << std::hex << std::setfill('0') << std::setw(2)
                    << static_cast<unsigned int>(digest[i]);

            return buf.str();
        }

his produces an equivalent 40-character hex digest (previously 40 hex chars from 5×8-hex-digit ints; now 40 hex chars from 20×2-hex-digit bytes) — so no observable behavior change other than fixing compilation.

Applying this one-line-block patch locally allowed the GPU build to compile and run successfully; verified working end-to-end with:

[LightGBM] [Info] This is the GPU trainer!!
[LightGBM] [Info] Using GPU Device: NVIDIA GeForce RTX 3060 Laptop GPU, Vendor: NVIDIA Corporation

Possible considerations for maintainers Since external_libs/compute appears to be a vendored/frozen snapshot rather than a live submodule tracking upstream boostorg/compute, it may be worth checking whether upstream Boost.Compute has already fixed this (and syncing), or applying this patch directly, or gating on BOOST_VERSION similar to the existing #if BOOST_VERSION >= 106600 check already present in the same file for header selection. Happy to submit a PR with this fix if maintainers confirm the preferred approach (patch vendored file directly vs. update the vendoring/submodule).

Disclaimer: I used an LLM to help me solve the issue and install the package with GPU support