# Possible Bug: Clang-FindBinUtils.cmake searches for clang-related binaries in an unexpected order

**URL:** https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832
**Category:** Development
**Created:** [September 15, 2026, 10:30am UTC](https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832 "2026-09-15T10:30:06Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![JanMatyasCodasip](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/73ab20/32.png) [@JanMatyasCodasip](https://discourse.cmake.org/u/JanMatyasCodasip)
#### Post date: [September 15, 2026, 10:30am UTC](https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832/1 "2026-09-15T10:30:06Z")

</div>

Hello,

I suspect that there is a bug in how Clang-FindBinUtils.cmake searches for clang-related executables (e.g. **clang-scan-deps** ). The order of the search appears incorrect.

The search iterates over two categories:

- first over all possible names (e.g. clang-scan-deps-20.1, clang-scan-deps-20, clang-scan-deps)
- and then over all possible locations (directories)

The current implementation iterates over the names first, and then over the directories. I believe the order should be swapped.

Pseudo-code:

```auto
// Current behavior (suspicious/buggy)

for (each possible name) {
    for (each possible directory) {
        check_if_file_exists(join_path(directory, name));
    }
}

// Expected behavior

for (each possible directory) {
    for (each possible name) {
        check_if_file_exists(join_path(directory, name));
    }
}

```

Concrete example:

Let’s have the following clang binaries on a Linux system:

```auto
/usr/bin:
    clang++-20
    clang-scan-deps-20
    ...

/opt/my_own_clang_build/bin:
    clang++
    clang-scan-deps
    ...

```

Let’s assume CMAKE\_CXX\_COMPILER variable is set to **/opt/my\_own\_clang\_build/bin/clang++**.

In such a case, Clang-FindBinUtils.cmake will search for name **clang-scan-deps-20** earlier than for name **clang-scan-deps**. For that reason, the result of the search will be **/usr/bin/clang-scan-deps-20** , and not the expected **/opt/my\_own\_clang\_build/bin/clang-scan-deps**.

Please let me know whether you agree that this is a bug, and whether the proposed fix looks all right to you.

---

<div class="post-metadata">

### Author: ![JanMatyasCodasip](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/73ab20/32.png) [@JanMatyasCodasip](https://discourse.cmake.org/u/JanMatyasCodasip)
#### Post date: [September 15, 2026, 10:32am UTC](https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832/2 "2026-09-15T10:32:52Z")

</div>

I’d like to add that I observed this suspected bug on CMake 3.13.8 but the current master seems to be affected, too.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 15, 2026, 12:40pm UTC](https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832/3 "2026-09-15T12:40:28Z")

</div>

Thanks. I’ve opened [CMake MR 12510](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/12510) to fix this by adding the `NAMES_PER_DIR` option to the [`find_program`](https://cmake.org/cmake/help/v4.4/command/find_program.html) calls for Clang companion tools.

---

<div class="post-metadata">

### Author: ![JanMatyasCodasip](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/73ab20/32.png) [@JanMatyasCodasip](https://discourse.cmake.org/u/JanMatyasCodasip)
#### Post date: [September 15, 2026, 12:59pm UTC](https://discourse.cmake.org/t/possible-bug-clang-findbinutils-cmake-searches-for-clang-related-binaries-in-an-unexpected-order/15832/4 "2026-09-15T12:59:53Z")

</div>

Hi Brad, thank you for quick reaction and preparing the fix. 👍

(I missed the fact that _find\_program_ has the _NAMES\_PER\_DIR_ option - which makes the fix easy.)