open-goal / jak-project

Reviving the language that brought us the Jak & Daxter Series
https://opengoal.dev
ISC License
2.73k stars 165 forks source link

FAILED: common/CMakeFiles/common.dir/custom_data/TFrag3Data.cpp.obj / FAILED: CMakeFiles/cmTC_d2c3d.dir/CurlTests.c.obj #3551

Closed shoober420 closed 3 weeks ago

shoober420 commented 3 weeks ago

Acknowledgements

Describe the Bug

Im compiling on Windows 11 using MSYS2. After running cmake -B build && cmake --build build -j 16, I get the following build error.

Build Logs: CMakeError.log CMakeOutput.log

[134/1164] Building CXX object common/CMakeFiles/common.dir/formatter/formatter_tree.cpp.obj C:/msys64/home/penny/jak-project/common/formatter/formatter_tree.cpp: In member function 'void FormatterTree::construct_formatter_tree_recursive(const std::string&, TSNode, FormatterTreeNode&, std::optional<std::__cxx11::basic_string >)': C:/msys64/home/penny/jak-project/common/formatter/formatter_tree.cpp:146:10: warning: unused variable 'debug_child' [-Wunused-variable] 146 | auto debug_child = ts_node_string(child_node); | ^~~ [138/1164] Building C object third-party/sqlite3/CMakeFiles/sqlite3.dir/sqlite3.c.obj ninja: build stopped: subcommand failed.

How To Reproduce

Open MSYS2 Clone repo Run cmake

Does this problem occur on original hardware or PCSX2?

Yes, it's unique to OpenGOAL

Expected Behavior

The build to complete.

Environment Information

i9-13900kf NVIDIA 4090 Windows 11 / MSYS2 Git Master (https://github.com/open-goal/jak-project/commit/b0b9fc4311c2a0a6e9a07b8b357d3b5e259043f4)

Game Version

NTSC 1.0 (black label)

Have you set the game to something other than 60fps?

No

xTVaser commented 3 weeks ago

The build logs that you included don't seem comprehensive, and the snippet from the compilers output is just a warning, not the actual error.

However, going off the title this is probably expected, __FUNCSIG__ is not available on all platforms. I assume this means that despite building on windows, your build environment is not using Visual C++.

If that is the case, then you could consider contributing a fix (i found a few when looking around, substituting __PRETTY_FUNCTION__ apparently works?), but it is somewhat out of scope -- we don't depend on or use things like msys2, cygwin or mingw. I wouldn't be surprised if you ran into other problems after solving this one.

shoober420 commented 3 weeks ago

My apologize, I havent compiled stuff on Windows very much. MSYS2 comes with different environments (https://www.msys2.org/docs/environments/). If I use the "clang64" exe, will it build using Visual C++?

xTVaser commented 3 weeks ago

Probably not, I believe the issue is with the underlying C++ libraries it's using, not the compiler itself. I've never used something like MSYS2 so I can't really help you.

Our readme has instructions for how we build on windows (we use clang, but we use microsoft's C++ standard library which you get via visual studio). https://github.com/open-goal/jak-project?tab=readme-ov-file#windows

Biswa96 commented 3 weeks ago

Many things need to be changed in this project before compiling with mingw gcc/clang. Some fixes were added in the third party project. Would it be possible to use system provided libraries like sdl, curl etc.? Or, do the fixes have to be imported in this project?

xTVaser commented 3 weeks ago

Are you asking me? I have no idea as I explained above, using all of these unix-like environments on windows is outside of scope. Using system provided libraries from my understanding is not standard on windows, it's more of a unix convention -- so yes that is another problem, if one of our many third-party dependencies doesn't support compiling with mingw/msys2/etc, that would also have to be patched.

I'm going to close this issue, if you have a PR to enable compilation in these environments that doesn't pose a maintenance burden on us I'd be happy to look at it, otherwise I'd recommend setting up a standard windows dev environment.