Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't build on Windows MSYS2 MinGW/Clang #189

Open
500-internal-server-error opened this issue Jan 4, 2025 · 7 comments
Open

Doesn't build on Windows MSYS2 MinGW/Clang #189

500-internal-server-error opened this issue Jan 4, 2025 · 7 comments
Assignees
Labels
Windows Windows platform is affected

Comments

@500-internal-server-error
Copy link

500-internal-server-error commented Jan 4, 2025

Describe the bug
This project doesn't build on Windows/MinGW

To Reproduce
Build as normal:

  1. git clone
  2. mkdir build && cd build
  3. cmake .. / cmake -G 'MinGW Makefiles' ..
  4. ninja / make -j$(nproc)
  • Results when building with MSYS2 UCRT64 GCC here
    • Results when enabling big objects and disabling tests here
  • Results when building with MSYS2 CLANG64 Clang here
    • Results when using same flags as on UCRT64 here

In between all these 4 runs, I clean out the build directory.

Expected behavior
Build on Windows/MinGW, as it does on Linux and Windows/Cygwin

Additional context
Tested using MSYS2 UCRT64, CLANG64, and MSYS environments, using their respective mingw-* and Cygwin GCC/Clang, CMake, Make, and Ninja packages

@gulrak gulrak added question Further information is requested Windows Windows platform is affected labels Jan 4, 2025
@gulrak
Copy link
Owner

gulrak commented Jan 4, 2025

Hi,

I guess I need more information than that, like versions used, maybe CMake output.

I just tried myself with a MinGW-w64 install with GCC14.2.0 and had two issues:

  • one was that the object size would be too big
  • the other was that I got a ton of errors when it tried to compile its own tests against the std::filesystem of the compiler, but I admit that I do not test that regularly on MinGW, and it is not relevant for the use of ghc::filesystem, more of a way to observe changes in differences for me

When I erased the build directory content and tried it again, but enabling big-obj and disabling the tests against std::filesystem by using (not using Ninja on that system, so make it is):

CXXFLAGS="-Wa,-mbig-obj" cmake -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DGHC_FILESYSTEM_BUILD_STD_TESTING=NO ..

I got for CMake:

C:/attic/filesystem/build $ CXXFLAGS="-Wa,-mbig-obj" cmake -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DGHC_FILESYSTEM_BUILD_STD_TESTING=NO ..
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/w64devkit/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/w64devkit/bin/c++.exe
-- Check for working CXX compiler: C:/w64devkit/bin/c++.exe - works
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- System name: Windows
-- Compiler ID: GNU
-- CMAKE_CXX_COMPILE_FEATURES: cxx_std_98;cxx_template_template_parameters;cxx_std_11;cxx_alias_templates;cxx_alignas;cxx_alignof;cxx_attributes;cxx_auto_type;cxx_constexpr;cxx_decltype;cxx_decltype_incomplete_return_types;cxx_default_function_template_args;cxx_defaulted_functions;cxx_defaulted_move_initializers;cxx_delegating_constructors;cxx_deleted_functions;cxx_enum_forward_declarations;cxx_explicit_conversions;cxx_extended_friend_declarations;cxx_extern_templates;cxx_final;cxx_func_identifier;cxx_generalized_initializers;cxx_inheriting_constructors;cxx_inline_namespaces;cxx_lambdas;cxx_local_type_template_args;cxx_long_long_type;cxx_noexcept;cxx_nonstatic_member_init;cxx_nullptr;cxx_override;cxx_range_for;cxx_raw_string_literals;cxx_reference_qualified_functions;cxx_right_angle_brackets;cxx_rvalue_references;cxx_sizeof_member;cxx_static_assert;cxx_strong_enums;cxx_thread_local;cxx_trailing_return_types;cxx_unicode_literals;cxx_uniform_initialization;cxx_unrestricted_unions;cxx_user_literals;cxx_variadic_macros;cxx_variadic_templates;cxx_std_14;cxx_aggregate_default_initializers;cxx_attribute_deprecated;cxx_binary_literals;cxx_contextual_conversions;cxx_decltype_auto;cxx_digit_separators;cxx_generic_lambdas;cxx_lambda_init_captures;cxx_relaxed_constexpr;cxx_return_type_deduction;cxx_variable_templates;cxx_std_17;cxx_std_20;cxx_std_23
Generating test runner for normal test...
-- Configuring done
-- Generating done
-- Build files have been written to: C:/attic/filesystem/build

and for make:

C:/attic/filesystem/build $ make
[  4%] Building CXX object test/CMakeFiles/filesystem_test.dir/filesystem_test.cpp.obj
[  8%] Linking CXX executable filesystem_test.exe
[  8%] Built target filesystem_test
[ 12%] Building CXX object test/CMakeFiles/filesystem_test_char.dir/filesystem_test.cpp.obj
[ 16%] Linking CXX executable filesystem_test_char.exe
[ 16%] Built target filesystem_test_char
[ 20%] Building CXX object test/CMakeFiles/filesystem_test_cpp17.dir/filesystem_test.cpp.obj
[ 25%] Linking CXX executable filesystem_test_cpp17.exe
[ 25%] Built target filesystem_test_cpp17
[ 29%] Building CXX object test/CMakeFiles/filesystem_test_cpp20.dir/filesystem_test.cpp.obj

... now a ton of deprecation warnings as ghc::filesystem implements api deprecated in C++20, but the test still builds fine ...

[ 33%] Linking CXX executable filesystem_test_cpp20.exe
[ 33%] Built target filesystem_test_cpp20
[ 37%] Building CXX object test/CMakeFiles/multifile_test.dir/multi1.cpp.obj
[ 41%] Building CXX object test/CMakeFiles/multifile_test.dir/multi2.cpp.obj
[ 45%] Linking CXX executable multifile_test.exe
[ 45%] Built target multifile_test
[ 50%] Building CXX object test/CMakeFiles/fwd_impl_test.dir/fwd_test.cpp.obj
[ 54%] Building CXX object test/CMakeFiles/fwd_impl_test.dir/impl_test.cpp.obj
[ 58%] Linking CXX executable fwd_impl_test.exe
[ 58%] Built target fwd_impl_test
[ 62%] Building CXX object test/CMakeFiles/exception.dir/exception.cpp.obj
[ 66%] Linking CXX executable exception.exe
[ 66%] Built target exception
[ 70%] Building CXX object examples/CMakeFiles/fs_dir.dir/dir.cpp.obj
[ 75%] Linking CXX executable fs_dir.exe
[ 75%] Built target fs_dir
[ 79%] Building CXX object examples/CMakeFiles/std_fs_dir.dir/dir.cpp.obj
[ 83%] Linking CXX executable std_fs_dir.exe
[ 83%] Built target std_fs_dir
[ 87%] Building CXX object examples/CMakeFiles/fs_du.dir/du.cpp.obj
[ 91%] Linking CXX executable fs_du.exe
[ 91%] Built target fs_du
[ 95%] Building CXX object examples/CMakeFiles/std_fs_du.dir/du.cpp.obj
[100%] Linking CXX executable std_fs_du.exe
[100%] Built target std_fs_du

And the examples simply work and the tests succeed.

@500-internal-server-error
Copy link
Author

I've added the results for running cmake .. above. Enabling big objects and disabling tests against std::filesystem has also fixed the problems for me, thanks.

@500-internal-server-error
Copy link
Author

Nevermind, it seems it's still a problem from MSYS2 CLANG64. -Wa,-mbig-obj is not an argument for LLVM/Clang it seems:

clang++: warning: argument unused during compilation: '-Wa,-mbig-obj' [-Wunused-command-line-argument]

Along with what seems to be the same errors as earlier, as if the tests haven't been disabled.

@gulrak
Copy link
Owner

gulrak commented Jan 5, 2025

Well, that is quite a difference, you reported it doesn't build with MinGW (which is a GCC), but you actually want to build with MSYS2-CLANG? So my test was actually a waste of time, please next time try to report the compiler you are actually using. :-(

Sadly I can't do any tests today, as I'm not at home, so it might need a few days for the next try.

@gulrak
Copy link
Owner

gulrak commented Jan 5, 2025

Oh, btw, the CMake output you added above is showing a MinGW GCC being selected, and the CMake part in the dump from the last message a Clang, so you mix them? You can't try to build MinGW and Clang in the same folder without deleting the build results, that will for sure be a mess, so please, which of the CMake outputs shows what you actually try to do?

I can say that I never tried building it on MSYS2-Clang, so I would expect issues to happen, on Windows it's tested only on Visual Studios cl.exe and MinGW's GCC yet, so supporting MSYS2 Clang might be more work, as each of the Windows compiler variants needs quite some fiddling to work, far more work than adding any additional "unixoid" platform was.

@gulrak gulrak self-assigned this Jan 5, 2025
@500-internal-server-error
Copy link
Author

500-internal-server-error commented Jan 5, 2025

Well, that is quite a difference, you reported it doesn't build with MinGW (which is a GCC), but you actually want to build with MSYS2-CLANG?

I am trying to build in UCRT64 and CLANG64, both of which previously produced errors. Your steps helped fix it for UCRT64 (based on GCC), but it remains broken for CLANG64 (based on LLVM).

So my test was actually a waste of time, please next time try to report the compiler you are actually using. :-(

Apologies, I am trying to build with both GCC (Cygwin/MSYS/UCRT64) and Clang (CLANG64). Your steps fixed it for GCC, but it is still broken for Clang.

so you mix them? You can't try to build MinGW and Clang in the same folder without deleting the build results

I do clean out the build folder when switching environments/compilers. Actually, when testing any changes, I clean out the build folder.

which of the CMake outputs shows what you actually try to do?

  • Results when building with MSYS2 UCRT64 GCC here
    • Results when enabling big objects and disabling tests here
  • Results when building with MSYS2 CLANG64 Clang here
    • Results when using same flags as on UCRT64 here

In between all these 4 runs, I clean out the build directory.

I can say that I never tried building it on MSYS2-Clang, so I would expect issues to happen

Ah, that's unfortunate. Thankfully, my primary interest is MSYS2-UCRT64, based on GCC, for which your steps have fixed. Though it would be nice if Clang was supported.

@gulrak
Copy link
Owner

gulrak commented Jan 5, 2025

I agree, it would be nice to support both.

So while I can't say what's going on with clang yet, I still look in into that. I just need to setup some msys2 for that, not using that myself anywhere yet, so supporting that takes a little more work.

@gulrak gulrak removed the question Further information is requested label Jan 5, 2025
@gulrak gulrak changed the title Doesn't build on Windows/MinGW Doesn't build on Windows MSYS2 MinGW/Clang Jan 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Windows Windows platform is affected
Projects
None yet
Development

No branches or pull requests

2 participants