2

If you build C++14 code with G++ and libstdc++, there's a library named libstdc++fs, which is separate from the rest of libstdc++, and contains the code for std::experimental::filesystem. If you don't link against it, you'll get undefined references.

The "trick" I'm using for overcoming this right now is:

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
        set(CXX_FILESYSTEM_LIBRARIES "stdc++fs")
endif()

and later:

target_link_libraries(my_target PUBLIC ${CXX_FILESYSTEM_LIBRARIES})

but - I don't like having to place this code in every project I work on. Is there a simpler or more standard idiom I could use? Some way this will all happen implicitly perhaps, with some CMake behind-the-scences magic?

einpoklum
  • 118,144
  • 57
  • 340
  • 684

1 Answers1

1

tl;dr: Nothing right now, wait for a newer CMake version

As @Pedro graciously points out, this is a known problem, and there is an open issue about it at KitWare's GitLab site for CMake:

Portable linking for C++17 std::filesystem

If using CMAKE_CXX_STANDARD=17 and std::filesystem, GCC requires linking of an extra library: stdc++fs. ... If C++17 is enabled, would it be worth automatically linking to stdc++fs for GCC versions which require this? Likewise for any quirks in other compilers or libraries.

The KitWare issue is about C++17, for which apparently you still need the separate extra library (i.e. it's not just because of the "experimentality" in C++14). Hopefully we'll see some traction on this matter - but

Note: If you're experiencing this problem with C++17's std::filesystem, you're in luck - that code is built into libstdc++ beginning with GCC 9, so if you're using g++ 9 or later, and std::filesystem, you should no longer experience this problem.

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • 1
    Exactly. If you are using an experimental feature, it is not extraordinary to depend on some special or unusual buildsystem solutions. When the experimental feature becomes mainstream, those unusual workarounds are no longer required. – Former contributor Feb 04 '20 at 19:56
  • [GCC implementation status](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017). c++11 is not yet complete right now in 2020. – Former contributor Feb 04 '20 at 20:05
  • _"Luckily, libstdc++fs was merged into libstdc++ for GCC 9"_, not entirely true. The C++17 `std::filesystem` symbols were merged into `libstdc++.so` but the `std::experimental::filesystem` ones are still in the separate `libstdc++fs.a` library, and will stay there. – Jonathan Wakely Feb 05 '20 at 13:35
  • @Pedro, C++11 is complete apart from a couple of minor things that nobody seems to care about. C++14 is complete. C++17 is only missing one tiny feature and one fairly large one. – Jonathan Wakely Feb 05 '20 at 13:43
  • @Pedro: Why is the C++11 implementation status relevant here? – einpoklum Feb 11 '20 at 13:44
  • @JonathanWakely: Edited to reflect your note. You could have edited yourself, BTW - you are welcome to edit my posts whenever you feel like it. – einpoklum Feb 11 '20 at 13:46