Fixing DAMX / Linuwu-Sense Compilation Error: Undeclared `strncpy

[jarski46]

**Fixing DAMX / Linuwu-Sense Compilation Error: Undeclared strncpy**

Tested on: Acer Nitro 5 AN515-58, CachyOS, kernel 7.2.0-1-cachyos (Clang/LLVM).

This issue is not limited to this specific model—it affects any Acer laptop using Linuwu-Sense on a distribution with a Clang/LLVM-built kernel where newer kernel headers have removed the strncpy() declaration.

---

Who Is Affected

If you are installing or reinstalling DAMX (Div Acer Manager Max) on a distribution with a recent Linux kernel compiled using Clang/LLVM (e.g., CachyOS) and encounter a Linuwu-Sense driver compilation error similar to this:

src/linuwu_sense.c:3574:5: error: call to undeclared library function 'strncpy'
      with type 'char *(char *, const char *, __size_t)'; ISO C99 and later do
      not support implicit function declarations [-Wimplicit-function-declaration]
    strncpy(input, buf, len);
    ^

— then this guide is for you.

---

Cause

Newer Linux kernels (confirmed on kernel 7.2.x) have removed the strncpy() declaration from the linux/string.h header. The kernel has been moving away from strncpy in favor of safer alternatives (such as strscpy()), and on the latest versions, this function has completely disappeared from the public API. Therefore, this is not a missing #include issue, but a missing declaration within the kernel headers themselves.

The Linuwu-Sense source code (in DAMX version 1.0.2, as well as the older 0.9.1) still uses strncpy() in three places, triggering a hard compilation error under Clang on these kernels.

---

Solution: Replacing strncpy with memcpy

In all three locations, the len variable is already safely bounded to the size of the target buffer (min(count, sizeof(buf) - 1)), and the string is explicitly null-terminated (\0) right after copying. As a result, memcpy() serves as a completely safe, functional equivalent without compromising security or behavior.

---

Step-by-Step Guide

1. Download the Latest DAMX Package Manually

Do not use remoteSetup.sh directly—it downloads and builds inside a temporary directory (/tmp) that gets removed after an error, leaving no time to apply the patch. Download the package manually:

mkdir -p ~/damx-install && cd ~/damx-install
curl -L -o DAMX-latest.tar.xz \
  "$(curl -s https://api.github.com/repos/PXDiv/Div-Acer-Manager-Max/releases/latest \
     | grep browser_download_url | grep '.tar.xz"' | cut -d '"' -f4)"
tar -xJf DAMX-latest.tar.xz
ls

Take note of the extracted folder name (e.g., DAMX-1.0.2)—you will need it in the following steps.

---

2. Navigate to the Driver Directory and Replace strncpy

cd ~/damx-install/DAMX-*/Linuwu-Sense   # match the folder name from Step 1

# Check how many occurrences exist in your version (usually 3)
grep -n "strncpy" src/linuwu_sense.c

Replace each occurrence found with memcpy using identical arguments. For version 1.0.2 (and typically other close versions), run:

sed -i 's/strncpy(input, buf, len);/memcpy(input, buf, len);/' src/linuwu_sense.c
sed -i 's/strncpy(input_buf, buf, len);/memcpy(input_buf, buf, len);/' src/linuwu_sense.c
sed -i 's/strncpy(str_buf, buf, len);/memcpy(str_buf, buf, len);/' src/linuwu_sense.c

Verify that no occurrences remain:

grep -n "strncpy" src/linuwu_sense.c

This should return an empty output. If grep shows any remaining lines with a different variable name (e.g., due to a different file version), replace them accordingly:

sed -i 's/strncpy(NAME, buf, len);/memcpy(NAME, buf, len);/' src/linuwu_sense.c

---

3. Build and Install from the Patched Directory

Return to the main package directory and execute the local installer (avoid running via curl | bash so that your patched copy is used):

cd ~/damx-install/DAMX-*
sudo LLVM=1 CC=clang ./setup.sh

Select option 4) Reinstall/Update DAMX Suite.

Note: The LLVM=1 CC=clang flags are only required on distributions running a kernel built with Clang/LLVM (e.g., CachyOS). If your kernel was built with GCC, omit these flags and simply run sudo ./setup.sh.

---

4. Done

The driver should now compile without errors (you may see two harmless warnings regarding & instead of &&—this is merely a code style issue, not a functional bug). The daemon and GUI will be installed automatically by the installer script.

---

Note for the Future

This patch will be needed again after every DAMX update until the fix is merged upstream. An issue report and proposed fix have been submitted to PXDiv/Div-Acer-Manager-Max. If the strncpy error reappears after updating your kernel or DAMX, simply repeat steps 1–3.

[CreatorOfBiontium]

Duplicate of #244

[marirkael-gif]

i love you so much holy

[jacksonff]

Thank you. I got it to compile following your guide (ANV16S-AI and CachyOS). I'm not a developer and that's why I'm making this question: is there any difference between memcpy and strscpy? Because most of the recent issues about the compile errors use strscpy instead of memcpy (but everyone seems to be using LLMs these days). Both seem to work but I'm curious about this.

[JunkerFarmer]

This fix works for my ANV15-51 running kernel 7.2.0-1-cachyos, so thank you for this. I think it'd be a good idea for you to push it from a fork, or if you don't want to, I could.

[jarski46]

@jacksonff
jacksonff
3d ago
Thank you. I got it to compile following your guide (ANV16S-AI and CachyOS). I'm not a developer and that's why I'm making this question: is there any difference between memcpy and strscpy? Because most of the recent issues about the compile errors use strscpy instead of memcpy (but everyone seems to be using LLMs these days). Both seem to work but I'm curious about this. 👍 :Good question! Glad it compiled for you.

Both memcpy and strscpy fix the build, but they're not doing quite the same thing under the hood:

• memcpy(dst, src, n) is a raw byte copy — it doesn't know or care that it's a string. It just copies n bytes, nothing more.
• strscpy(dst, src, size) is the newer kernel-preferred replacement for strncpy. It guarantees the destination is always null-terminated, and it returns an error code (-E2BIG) if the source was too long and got truncated — so the caller can actually detect truncation if it wants to.

In these three specific call sites, though, the code already does the safety work manually before calling the copy function: len is pre-clamped with min(count, sizeof(buf) - 1), and the buffer is explicitly null-terminated right after the copy (buf[len - 1] = '\0'). Since the length is already bounded and the null-termination is already handled by hand, memcpy produces the exact same result as the original strncpy did — no behavior changes, it's the most minimal possible fix.

strscpy would arguably be the more "correct" modern choice (it's what the kernel itself has been migrating toward), and it would additionally let you check for truncation if you cared to — but it needs a slightly different call shape (it takes the destination buffer size, not a pre-computed length, and returns a value you could check). Since the existing code never checked for truncation anyway and already did the clamping itself, I went with the smaller change to keep the diff minimal and avoid touching logic that wasn't broken.

Both are safe here — strscpy is just the more idiomatic long-term choice if someone wants to clean this up further.

[abduvaliy-hbai]

Adding another confirmation: I hit this exact issue on Arch Linux 7.2.2-arch1-1 too, so this affects more than CachyOS/LLVM setups.

I pushed a tested branch with the minimal driver-side change here:
https://github.com/abduvaliy-hbai/Linuwu-Sense/tree/fix/linux-7-2-strncpy-removal

There is also an upstream PR for the same fix:
0x7375646F/Linuwu-Sense#128

On my machine, after rebuilding/installing the patched DKMS module and restarting DAMX, the daemon went from linuwu_sense module not found / UNKNOWN back to detecting NITRO and exposing fan/thermal/battery features.