# CMake's equivalent of AC\_SEARCH\_LIBS (to find std::filesystem)?

**URL:** https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818
**Category:** Code
**Created:** [January 12, 2022, 10:22am UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818 "2022-01-12T10:22:56Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![mojca](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mojca/32/610_2.png) [@mojca](https://discourse.cmake.org/u/mojca)
#### Post date: [January 12, 2022, 10:22am UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818/1 "2022-01-12T10:22:56Z")

</div>

In autotools one can do the following for example:

```auto
AC_SEARCH_LIBS(clock_gettime, rt)

```

which will add the `-lrt` flag only when it’s available and needed. (I’m not claiming that my statement is 100% exact, but this one-liner performs a set of tests and as a consequence works across a very wide range of operating systems, compilers and standard libraries and either adds the flag or skips it.)

I would like to use a similar functionality in CMake to figure out whether or not I need the flag `-lstdc++fs` to use `std::filesystem` (with a C++17-capable compiler). There’s an existing thread in [Correct way to link std::filesystem with GCC 8?](https://discourse.cmake.org/t/correct-way-to-link-std-filesystem-with-gcc-8/4121), but the accepted solution `link_libraries( "$<$<AND:$<CXX_COMPILER_ID:GNU>,$<VERSION_LESS:$<CXX_COMPILER_VERSION>,9.0>>:-lstdc++fs>" )` sounds like a nightmare if I also want to properly support all the compilers and different standard libraries (`libc++`, `stdlibc++`). It sounds fine for `gcc`, but one needs to do the same for `clang` and who-knows-which-other-compilers. Another solution uses 60 lines of code to achieve roughly the equivalent of what autotools do with a single line.

What I would really like to achieve is the following:

- try to compile with the `-lstdc++fs` flag
- try to compile without the flag

(I don’t care in which order) and provide feedback about the option that works correctly for `std::filesystem`, without having to provide tons of hardcoded knowledge about various compiler and operating system versions (that require, don’t require or refuse to work with that flag).

In this particular case I don’t want to care too much about really old compilers, but supporting gcc 8 (for Debian and Ubuntu) is still somewhat unavoidable, and I definitely need support for clang on various operating systems.

---

<div class="post-metadata">

### Author: ![petwu](https://discourse.cmake.org/user_avatar/discourse.cmake.org/petwu/32/1399_2.png) [@petwu](https://discourse.cmake.org/u/petwu)
#### Post date: [January 12, 2022, 2:24pm UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818/2 "2022-01-12T14:24:56Z")

</div>

It seems like there is an [ongoing discussion](https://gitlab.kitware.com/cmake/cmake/-/issues/17834) on whether this is something that should be addressed in upstream CMake and if so how. So unfortunately, there is no “correct” solution provided by CMake and for now every project has to come up with their own approach to solve this.

IMHO a reasonable and well working approach is to use a `FindFilesystem` module like [this](https://github.com/lethal-guitar/RigelEngine/blob/master/cmake/Modules/FindFilesystem.cmake) one. Simply save it somewhere in your project (commonly a `cmake/` directory) and prepend that path to [CMAKE\_MODULE\_PATH](https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html) in order to use it. The module performs several `check_cxx_source_compiles()` checks (+ 1 hard-coded special case) to figure out which flag is required and then provides and interface target as an abstraction that can be used like this:

```cmake
find_package(Filesystem REQUIRED)
target_link_libraries(myLib PRIVATE Filesystem::Filesystem)

```

This approach is analogous to the [FindThreads](https://cmake.org/cmake/help/latest/module/FindThreads.html) module with its `Threads::Threads` target provided by CMake.

---

<div class="post-metadata">

### Author: ![mojca](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mojca/32/610_2.png) [@mojca](https://discourse.cmake.org/u/mojca)
#### Post date: [January 12, 2022, 7:42pm UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818/3 "2022-01-12T19:42:56Z")

</div>

Awesome, thank you. I took the original module and that one works fine even with gcc 7.

I keep my fingers crossed that CMake will eventually include some useful code into the codebase to better support this library.

Of course I’m still curious how to generally solve this with other libraries when there’s no-one to write those 250 lines of code for you.

---

<div class="post-metadata">

### Author: ![alex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/alex/32/125_2.png) [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [January 13, 2022, 1:37am UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818/4 "2022-01-13T01:37:21Z")

</div>

> [@mojca](#):
>
> Of course I’m still curious how to generally solve this with other libraries when there’s no-one to write those 250 lines of code for you.

Most other libraries don’t have a different way of linking to them for each compiler/toolchain; you just `find_package`, `pkg_check_modules`, or create some `IMPORTED` targets out of `find_library` calls yourself.

It’s rather ironic that the standard filesystem library is one of the most inconsistent across compiler vendors.

---

<div class="post-metadata">

### Author: ![dimpase](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dimpase/32/3009_2.png) [@dimpase](https://discourse.cmake.org/u/dimpase)
#### Post date: [December 15, 2022, 9:35am UTC](https://discourse.cmake.org/t/cmakes-equivalent-of-ac-search-libs-to-find-std-filesystem/4818/5 "2022-12-15T09:35:42Z")

</div>

The point is that different OSs might place a function in a differently named library; e.g. standard C library functions dealing with complex numbers might end up in `libc`, or in `libm`, there is no telling without actually checking each particular OS, whereas autoconf would allow creating a universally valid test.
