adding_MinGW_build_support

[RohanKrMahato]

#Building the Core Using MinGW

This is the Build log file:- Build_Log.txt

To compile the core using MinGW:-
open command prompt (admin)
go to the core directory

mkdir build
cd build
cmake -G "MinGW Makefiles" -DOPTION_FORK_SAFE=OFF -DOPTION_BUILD_PLUGINS_BACKTRACE=OFF ..
cmake --build .

this will build the core using minGW (release).
For Debug add -DCMAKE_BUILD_TYPE=Debug

Fixes #484

Type of change

• New feature (non-breaking change which adds functionality)

[viferga]

I am leaving this as draft until you pass the CIs, specially the formatting one. It would be very important to add testing in the windows CI or similar, so we have continuous testing of MinGW compiler.

[viferga]

I am leaving some reference here for you:

• Compile with MinGW on GitHub Actions: https://stackoverflow.com/a/75758843
• Maybe it will be needed to add MinGW installation here: https://github.com/metacall/core/blob/develop/tools/metacall-environment.ps1
• Support for building with MinGW here:

  core/tools/metacall-configure.ps1

  Line 427 in 04e0d73

  # Execute CMake

Maybe we can create new scripts for that, or reuse the ones with PowerShell, we should investigate the pros and cons, but the CI is necessary in order to continuous test the new target (MinGW).

[RohanKrMahato]

Thanks Sir, I will look into it :)

[RohanKrMahato]

Segmentation Fault in Ctest

We encountered an issue where Ctest was failing due to segmentation faults in test programs, even after adding this case Line 35.

Steps Taken:

1. Initial Build Attempt:

   • To build run the following command in the core:

     mkdir build
     cd build
     cmake -G "MinGW Makefiles" ..
     cmake --build .

   • This failed with function pointer exceptions.

2. Issue with Function Pointer Type Casting:

   • In MSVC, function pointers can be type cast to void*, but in MinGW, function pointers are of type void (*)() and cannot be directly cast to void*. Our MSVC code used:

           [ 57%] Building CXX object source/loaders/ext_loader/CMakeFiles/ext_loader.dir/source/ext_loader_impl.cpp.obj
      C:\Users\Rohan Kumar Mahato\Desktop\core\source\loaders\ext_loader\source\ext_loader_impl.cpp: In function 'int ext_loader_impl_discover(loader_impl, loader_handle, context)':
      C:\Users\Rohan Kumar Mahato\Desktop\core\source\loaders\ext_loader\source\ext_loader_impl.cpp:349:37: error: invalid 'static_cast' from type 'dynlink_symbol_addr' {aka 'void (*)()'} to type 'void*'
        349 |                 function_cast.ptr = static_cast<void *>(ext.addr);
            |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      mingw32-make[2]: *** [source\loaders\ext_loader\CMakeFiles\ext_loader.dir\build.make:94: source/loaders/ext_loader/CMakeFiles/ext_loader.dir/source/ext_loader_impl.cpp.obj] Error 1
      mingw32-make[1]: *** [CMakeFiles\Makefile2:6021: source/loaders/ext_loader/CMakeFiles/ext_loader.dir/all] Error 2
      mingw32-make: *** [Makefile:155: all] Error 2

   • This led to type casting errors in MinGW.

3. Adding MinGW-Specific Cases:

   • We added cases for MinGW in dynlink_impl_symbol_win32.h and dynlink_impl_win32.c. The implementation for MinGW was adapted to be similar to Unix (dynlink_impl_symbol_unix.h and dynlink_impl_unix.c).

   • Changes were made at:

     • Line 66
     • Line 57
     • Line 84

4. Whitespace Issue in Script:

   • Fixed a whitespace issue in source/detours/funchook_detour/scripts/download.bat.in.

5. Build Configuration Options:

   • To bypass other issues, we used:

     -DOPTION_FORK_SAFE=OFF -DOPTION_BUILD_PLUGINS_BACKTRACE=OFF

   • This allowed the core to compile successfully.

6. Code Formatting:

   • Ensured the code was formatted with clang-format version 11 (important to match formatting behavior across versions).

7. Workflow for MinGW:

   • Created a GitHub Actions workflow for MinGW:
     windows-test.yml#L68

8. DLL Loading Issue:

   • During Ctest, some .dll files were missing, causing errors like:

     Failed to load: D:/a/core/core/build/rapid_json_seriald.dll with error code [126]: The specified module could not be found.
     

   • Fixed this in dynlink_impl_win32.c:
     Line 42.

Segmentation Fault Debugging:

• When running Ctest, segmentation faults occurred during tests (observed on GitHub Actions). Locally, we debugged with GDB since address sanitizers are not supported in MinGW.

• GDB Debugging:

  • Ran one of the test executables (reflect-scope-testd.exe) and observed:

      [New Thread 11520.0xca0]
      [New Thread 11520.0x1884]
      [New Thread 11520.0x2a98]
      [==========] Running 1 test from 1 test suite.
      [----------] Global test environment set-up.
      [----------] 1 test from reflect_scope_test
      [ RUN      ] reflect_scope_test.DefaultConstructor
      Debug: Loading plugin: rapid_json_seriald
      Debug: Loading plugin symbol: dynlink_symbol_rapid_json_serial_impl_interface_singleton
      
      Thread 1 received signal SIGSEGV, Segmentation fault.
      0x00007ffc8e8dbcca in dynlink_impl_interface_symbol_win32 (handle=<optimized out>, impl=<optimized out>,
          name=<optimized out>, addr=0x5ff720)
          at C:\Users\Rohan Kumar Mahato\Desktop\core\source\dynlink\source\dynlink_impl_win32.c:86
      86              (*addr)->symbol = (dynlink_symbol_addr_win32_impl)proc_addr;
      (gdb)
    

  • The fault was traced to:
    dynlink_impl_interface_symbol_win32

9. Additional Changes for MinGW:
   • Tried adding MinGW-specific handling at:
     dynlink_impl_symbol_win32.h#L35
   • However, this did not resolve the segmentation fault issue.

Current Status:

The code compiles but still fails Ctest due to segmentation faults in test programs. We need to continue debugging the root cause of the segmentation fault in dynlink_impl_interface_symbol_win32.