# Extending find\_library to take NAME\_SUFFIXES

**URL:** https://discourse.cmake.org/t/extending-find-library-to-take-name-suffixes/15520
**Category:** Development
**Created:** [February 20, 2026, 4:12pm UTC](https://discourse.cmake.org/t/extending-find-library-to-take-name-suffixes/15520 "2026-02-20T16:12:02Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![KBentley57](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kbentley57/32/474_2.png) [@KBentley57](https://discourse.cmake.org/u/KBentley57)
#### Post date: [February 20, 2026, 4:12pm UTC](https://discourse.cmake.org/t/extending-find-library-to-take-name-suffixes/15520/1 "2026-02-20T16:12:02Z")

</div>

Hi guys,

I was in the process of writing a module for finding libusb-1.0, and I hit a snag that has been a common pattern I’ve had for a while. Sometimes I have an SDK that requires a library, like libusb-1.0. I have that library on my machine, but I don’t have the dev package for it. This is common on many systems I develop on, redhat 8/9, rocky linux, and so on. Most modules will fail to find packages due to the missing headers, and it then creates a situation where a lot of workarounds need to be done, in a not so elegant way.

Before anyone asks, yes, there are several, probably 50 versions of Find//usb//.cmake that I could use, and pkg-config, and all of that. This question isn’t about libusb-1.0 so much as it displays why I’m going to ask for ideas here.

I have on my machine

`usr/lib64/libusb-1.0.so.0`  
`/usr/lib64/libusb-1.0.so.0.2.0`

and a standard call wont get it.

`find_library(LIBUSB_LIBRARY`  
`NAMES ${_LIBUSB_LIB_NAMES}`  
`HINTS ${_LIBUSB_SEARCH_HINTS}`  
`PATHS ${_LIBUSB_SEARCH_PATHS}`  
`PATH_SUFFIXES`  
`lib`  
`lib64`  
`lib32`  
`lib/x86_64-linux-gnu`  
`lib/i386-linux-gnu`  
`lib/arm-linux-gnueabihf`  
`lib/aarch64-linux-gnu`  
`DOC “libusb library”`  
`)`

Due to the suffix on the library. I see that i might be able to append and then remove from the list `CMAKE_FIND_LIBRARY_SUFFIXES`, but that doesn’t feel particularly clean. I could call `find_file` and get it that way, but that’s not really in the spirit of finding a library either.

Would it be possible to extend find\_library just a bit so that it can take a variable like NAME\_SUFFIXES so that a user could specify something like

NAME\_SUFFIXES ““ “.0” “.1”

The computed name might then become usb-1.0\<.so\>\<.0\>

or similar? That would give a lot of freedom in finding more libraries, without all the extra workaround that gives area for breakage.

I’m open to other ideas too, if I’m completely being oblivious to something.

Thanks!

Kyle B

---

<div class="post-metadata">

### Author: ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [February 20, 2026, 9:54pm UTC](https://discourse.cmake.org/t/extending-find-library-to-take-name-suffixes/15520/2 "2026-02-20T21:54:37Z")

</div>

You would still need the header file(s) that are usually in the same package as the .so link.

---

<div class="post-metadata">

### Author: ![KBentley57](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kbentley57/32/474_2.png) [@KBentley57](https://discourse.cmake.org/u/KBentley57)
#### Post date: [February 20, 2026, 9:59pm UTC](https://discourse.cmake.org/t/extending-find-library-to-take-name-suffixes/15520/3 "2026-02-20T21:59:06Z")

</div>

That’s the case 99% of the time Hendrik, but I’ve got a few hardware SDK’s that leave some of the library resolution up to the user. It can be the case where having the library is enough, and the headers aren’t required.