Update to libc++ 17.0.6 #2
Conversation
There was a problem hiding this comment.
Thanks a lot for your work and the conversation via e-mail!
Something seems to be off with the encoding of the changed libc++.vcxproj and libc++.vcxproj.filters files. The diff view of GitHub shows every line as changed when that shouldn't be the case.
Could you check and fix that, so I can continue the review?
Has this also been tested with VS2019 or the new version VS2022-only?
solemnwarning
force-pushed
the
libc++-17.0.6
branch
from
f89dee5
to
f8c1635
Compare
|
Hi Colin, VS automatically converted the project files to CRLF line endings on save, I've changed them back to LF so the changes show up correctly on GitHub. I haven't tried this final version with VS2019, as I had issues both with the compiler's incomplete C++20 support and unrelated issues with the older |
| <ClCompile Include="filesystem\directory_entry.cpp" /> | ||
| <ClCompile Include="filesystem\directory_iterator.cpp" /> | ||
| <ClCompile Include="filesystem\filesystem_clock.cpp" /> | ||
| <ClCompile Include="filesystem\filesystem_error.cpp" /> | ||
| <ClCompile Include="filesystem\operations.cpp" /> | ||
| <ClCompile Include="filesystem\path.cpp" /> |
There was a problem hiding this comment.
@solemnwarning I recall from our conversation that you had problems with std::filesystem and disabled it entirely.
If that is still the case, we can probably skip compiling everything from the filesystem subdirectory, just like I did for libc++ 11 and VS2019.
Or is std::filesystem supported now?
There was a problem hiding this comment.
I had to re-enable it for one of the libraries I'm using in rehex, however the compile errors went away like magic, it might depend exactly what std::filesystem functionality is being used in the application.
I had another issue where libc++'s std::chrono was linking against GetSystemTimePreciseAsFileTime(), which I made a note of to investigate and fix later (probably with another wrapper in EnlyzeWinCompatLib), but when I went to do that, it had resolved itself.
I think perhaps I was compiling with the wrong _WIN32_WINNT at some point, and exactly how much works on what Windows version is going to depend on exactly what C++ functionality the final application is using.
There was a problem hiding this comment.
Just as an FYI, I threw this together to verify libc++ in general still works in NT4: https://github.com/solemnwarning/nt4-exe-test
It uses a bit of STL, and threads/atomics/exceptions, which is obviously leaving large swathes of libc++ untested... it would be nice to get libc++'s test suite compiled and running on an NT4 target, but thats probably a huge amount of work neither of us really want to get into right now :D
This commit imports the sources/headers from libc++ 17.0.6 and updates the VS project to build it for improved C++20 support. VS2022 is required for the C++20 compiler support.
solemnwarning
force-pushed
the
libc++-17.0.6
branch
from
f8c1635
to
a5544c4
Compare
This commit imports the sources/headers from libc++ 17.0.6 and updates the VS project to build it for improved C++20 support.
VS2022 is required for the C++20 compiler support.