When compiling on windows i get a few errors about ld.exe

[Algiuxs]

see the log
https://paste.rs/YmDqu.txt

So i came to the compiling step and fixed a few errors in isrenderdocactive and a few other places, but i get ld.exe errors, i didnt modify the cmake files also i didnt modify the conanfile, im compiling on widnows compiling with msys2 ucrt64 compiler with the conan version of ninja.

[neobrain]

Does it help if you make the GPU core link against the platform and/or framework targets?

[Algiuxs]

helped a little: https://paste.rs/t4Yp0.txt

added to the linked file: target_link_libraries(video_core PRIVATE framework platform)

[neobrain]

Cool. The remaining errors seem to be the same issue, but it's more tricky to resolve: The GPU core uses symbols that are defined in the main emulator executable, which is not a problem for the gcc/clang linkers but apparently for msvc. I'm not sure if there's an easy way to resolve this... Perhaps MSVC has a compiler flag to allow this type of linking behavior?

[Algiuxs]

Well I'm not using MSVC I'm using GCC and g++

[Algiuxs]

Also quick question, does it compile for you after downloading the source code and not changing it on Linux, because on windows it complained in a few places about filesystem, it couldn't compile, because the type was mismatched it required strings but was filesystem path or something like that.

[neobrain]

Well I'm not using MSVC I'm using GCC and g++

Err, right, but apparently something is different about your msys configuration that makes linking work differently than on Linux/macOS.

Also quick question, does it compile for you after downloading the source code and not changing it on Linux, because on windows it complained in a few places about filesystem, it couldn't compile, because the type was mismatched it required strings but was filesystem path or something like that.

It's working out of the box here when using dependencies from Conan, yes. I can see why the std::filesystem interface would behave slightly different on Windows though given UTF-16 path encoding though.

If you end up getting things working (looks like the linker issue is the only blocker atm), you're definitely welcome to open a PR with the fixes :)

[neobrain]

Wild guess, does turning the video_core target from a SHARED library into a STATIC one fix it? (If it does, you won't need the previous change of linking in platform and framework)

[Algiuxs]

now i get some errors from teakra and gcc not finding the main function.
Yes i know the log is cut off.
https://paste.rs/mnCym.txt

[neobrain]

Seems like we're making progress, but no idea what's going on there :(

Possibly vaguely related: msys2/MINGW-packages#23708

[Algiuxs]

Should I just try to compile with clang?

[neobrain]

Up to you. The teakra thing can probably be fixed, but I've never tried that build setup. Clang on Windows sounds like it should behave more consistent with Linux/macOS.

[Algiuxs]

msys ucrt64 (this i was previously using and now too) with gcc 15.1.0 kinda fixed the problem, i just don't know how to solve these errors:
https://paste.rs/jdo1h.txt

[neobrain]

The TCP server isn't necessary for basic operation. Dropping it (and then probably also framework/console.cpp and gdb_stub.cpp) from the CMakeLists.txt files and then commenting out any uses of the GDB stub or network console should fix these errors.

[neobrain]

If the WinMain error persists, I think we just need to include "SDL_main.h" in main.cpp link the main executable against SDL2::SDLmain (or a similarly named target).

[Algiuxs]

Got it to build!! No deletion required, just a #define SDL_MAIN_HANDLED in the main at the top and some winsock include
(note: after compilation if you dont launch conanrun the prgram doesnt launch unless you copy the sdl.dll file to mikage .exe directory)
Also if i submit a pr for this some work will need to be put into it, because i havent tested my modifications on linux and there is a high chance it wont build