[libcxx] Fix freestanding build with filesystem disabled on Windows

[moleium]

Building libc++ for freestanding targets on Windows with LIBCXX_ENABLE_FILESYSTEM=OFF fails due to compilation errors.

The root cause is twofold:

1. path.cpp and filesystem_error.cpp are compiled even when filesystem is disabled. These files depend on wide character and localization support, which freestanding builds typically don't provide.
2. print.cpp transitively depends on filesystem headers for Windows error reporting, pulling in even when the feature is disabled.

This patch fixes both problems by:

• Guarding filesystem sources in src/CMakeLists.txt with LIBCXX_ENABLE_FILESYSTEM
• Making print.cpp call GetLastError() directly when filesystem support is unavailable

Fixes #164074

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: miyav (moleium)

Changes

Building libc++ for freestanding targets on Windows with LIBCXX_ENABLE_FILESYSTEM=OFF fails due to compilation errors.

The root cause is twofold:

1. path.cpp and filesystem_error.cpp are compiled even when filesystem is disabled. These files depend on wide character and localization support, which freestanding builds typically don't provide.
2. print.cpp transitively depends on filesystem headers for Windows error reporting, pulling in <filesystem> even when the feature is disabled.

This patch fixes both problems by:

• Guarding filesystem sources in src/CMakeLists.txt with LIBCXX_ENABLE_FILESYSTEM
• Making print.cpp call GetLastError() directly when filesystem support is unavailable

Fixes #164074

---

Full diff: https://github.com/llvm/llvm-project/pull/164602.diff

2 Files Affected:

• (modified) libcxx/src/CMakeLists.txt (+3-3)
• (modified) libcxx/src/print.cpp (+4-2)

diff --git a/libcxx/src/CMakeLists.txt b/libcxx/src/CMakeLists.txt
index f59fe0e08fccb..78b88a9e8c912 100644
--- a/libcxx/src/CMakeLists.txt
+++ b/libcxx/src/CMakeLists.txt
@@ -9,10 +9,7 @@ set(LIBCXX_SOURCES
   error_category.cpp
   exception.cpp
   expected.cpp
-  filesystem/filesystem_clock.cpp
-  filesystem/filesystem_error.cpp
   filesystem/path_parser.h
-  filesystem/path.cpp
   functional.cpp
   hash.cpp
   include/apple_availability.h
@@ -117,6 +114,9 @@ endif()
 
 if (LIBCXX_ENABLE_FILESYSTEM)
   list(APPEND LIBCXX_SOURCES
+    filesystem/filesystem_clock.cpp
+    filesystem/filesystem_error.cpp
+    filesystem/path.cpp
     filesystem/directory_entry.cpp
     filesystem/directory_iterator.cpp
     filesystem/file_descriptor.h
diff --git a/libcxx/src/print.cpp b/libcxx/src/print.cpp
index 3f2baa6dcc60b..1b6a800e1a003 100644
--- a/libcxx/src/print.cpp
+++ b/libcxx/src/print.cpp
@@ -13,8 +13,6 @@
 
 #include <__system_error/system_error.h>
 
-#include "filesystem/error.h"
-
 #if defined(_LIBCPP_WIN32API)
 #  define WIN32_LEAN_AND_MEAN
 #  define NOMINMAX
@@ -51,7 +49,11 @@ __write_to_windows_console([[maybe_unused]] FILE* __stream, [[maybe_unused]] wst
                     __view.size(),
                     nullptr,
                     nullptr) == 0) {
+#    if _LIBCPP_HAS_FILESYSTEM
     std::__throw_system_error(filesystem::detail::get_last_error(), "failed to write formatted output");
+#    else
+    std::__throw_system_error(error_code(GetLastError(), system_category()), "failed to write formatted output");
+#    endif
   }
 }
 #  endif // _LIBCPP_HAS_WIDE_CHARACTERS

[philnik777]

As I said in the issue, we shouldn't disable these just because filesystem isn't available. These features don't depend on a filesystem on the platform existing.

[moleium]

As I said in the issue, we shouldn't disable these just because filesystem isn't available. These features don't depend on a filesystem on the platform existing.

I understand the principle. The issue is that the path implementation on Windows has hard dependencies on localization and wide characters

[moleium]

How would you suggest resolving that conflict?

[philnik777]

How would you suggest resolving that conflict?

I would suggest finishing up the locale base API and no-locale stuff. That would allow us to provide most of the localization API, making the dependence a non-problem.

[moleium]

I would suggest finishing up the locale base API and no-locale stuff.

Implementing a full locale API seems like a long-term project. What would you suggest as an interim solution? what i'm aiming for is a freestanding windows-like build of libcxx (no localization and wide character support)

[ldionne]

I don't think implementing what @philnik777 is suggesting is necessarily that big of a deal. We already refactored a lot of the locale API layer and we're down to something fairly clean, except for the old shim layer we still have for a few platforms. It's certainly not trivial, but I think this is the easiest and cleanest path to fixing this issue properly and for the long term.

For example, we have started creating bundles of locale functions that can be reused when you want to assume the C locale: https://github.com/llvm/llvm-project/blob/main/libcxx/include/__locale_dir/support/fuchsia.h#L158

I understand the principle. The issue is that the path implementation on Windows has hard dependencies on localization and wide characters

It's more than a principle, though. There's a reason why we enabled some parts of <filesystem> on platforms where no filesystem is available: people wanted to do e.g. path manipulation and that's entirely fine since that's just string operations under the hood. So there are actual users of this, which this patch would break. I totally understand what you're trying to achieve, however the library is currently designed in this way for a reason, so we'll need to keep that working.

I do think that being able to assume the C locale (by providing the appropriate locale base API layer) on platforms that don't support localization is the right approach, and it would greatly simplify other things. For example, we'd get rid of _LIBCPP_HAS_NO_LOCALIZATION in probably 90% of the places where it's currently used.

[moleium]

@ldionne @philnik777 Thank you for the feedback.

I see the issue here, so i agree with the goal of keeping std::path available.
If you take a look at the implementation inconsistency in <__filesystem/path.h> On Windows, _PathExport and its dependencies are guarded only by _LIBCPP_WIN32API which assumes locale support. Other parts of the same header like _PathCVT, correctly use _LIBCPP_HAS_LOCALIZATION.

Instead of my removing the CMake sources, applying _LIBCPP_HAS_LOCALIZATION guard consistently within the headers would fix the issue without breaking existing users.

I can update the PR with that approach if you agree.