SFX archive - same setup - 2 machines - some projects won't compile on 2nd machine

[TheArkive]

Several weeks ago (maybe a few months by now) I setup the sfx archive (msys2-base-x86_64-20210725.sfx.exe) on my system. It took several minutes to go through several "key ring" updates. That particular setup is still working fine on that machine.

I'm trying to setup msys2 on another PC now (windows), and it's completing in under a minute with several failures.

I'm wondering if this has to do with some of the certificate issues happening lately...

Anyways, the end result is that now I have projects that used to compile fine, but now some references are being reported as not declared in "this scope".

I was hoping to find a complete log in the msys2 root dir, but i was only able to take the screenshot during initial setup.

[TheArkive]

If there is any other method i can use to setup the sfx archive to troubleshoot please let me know.

I have msys2 root defined in MSYS2_ROOT user var and defined in user %PATH%.

I use the msystem launcher (linked from msys2 site > Launchers - with a few custom doskeys). This launcher has been working fine since I started using it, but I think the underlying issue is the failed keyring updates.

[jeremyd2019]

I'm not seeing any failure in the keyrings in that, just normal errors retrieving via WKD, but it then succeeds updating them via hkps://keyserver.ubuntu.com as expected

[TheArkive]

Oh. I guess I stand corrected. Well, then the remining issue is that some of my super light projects used to compile normally (actually just displaying #defined win32 constant values in cmd for another project to catalog them), but now I'm getting a "not defined in this scope" error from the g++ compiler.

Is this the proper repo to report that or ask for help?

The oddity is that the "old setup" (oddly using the exact same setup file version and same env vars) still works and compiles normally.

Here's a small example of a file that compiles fine on one machine, but not the new machine with a new msys2 setup.

#include <iostream>
#include <WinSock2.h>
#include <mstcpip.h>

int main() {
    std::cout << "SIO_ACQUIRE_PORT_RESERVATION = " << SIO_ACQUIRE_PORT_RESERVATION << std::endl;

    return 0;
}

Here is the output error:

g++ -o test_const.exe test_const.cpp
test_const.cpp: In function 'int main()':
test_const.cpp:6:55: error: 'SIO_ACQUIRE_PORT_RESERVATION' was not declared in this scope
    6 |     std::cout << "SIO_ACQUIRE_PORT_RESERVATION = " << SIO_ACQUIRE_PORT_RESERVATION << std::endl;
      |

I'm quite new to C++ and still getting comfortable with the actual workings of the compiler, so there is definitely room for error on my part, but it is odd that the apparent identical setup doesn't work the same on 2 different machines.

I have the same VC++ runtimes installed, both win 10 with latest updates... Anything else I can try or check?

[jeremyd2019]

I don't see that defined in the mingw-w64 headers. @Biswa96 ?

[Biswa96]

Hi @TheArkive

• I have sent patch to upstream mingw-w64 here https://sourceforge.net/p/mingw-w64/mailman/message/37364434/
• You can download the patch file and apply it to ${MINGW_PREFIX}/${MINGW_CHOST}/include/mstcpip.h file.
• Or wait for some time for new mingw-w64-headers package. There have been multiple updates of that package recently.
• If you have any general questions or request you can ask it in msys2's IRC, Discord or Gitter.

[TheArkive]

Thanks @Biswa96 !

It turns out, I was mistakenly using Build Tools compiler, not g++, my apologies. massive facepalm here 🤦. Just wanted to set the record straight. The machine I thought that was "properly compiling" that #define ended up not compiling with the same err msg when using g++.

Those defines were in the Win10 sdk headers i was looking at 🤦. So @jeremyd2019 yah, you're definitely right, that var was definitely not defined in mingw headers.

Thanks again.

[jeremyd2019]

Ah, ok, was wondering because it's unlikely that mingw-w64 would have removed a define if they had it earlier.

[TheArkive]

Ah, ok, was wondering because it's unlikely that mingw-w64 would have removed a define if they had it earlier.

Yah i thought that was weird too. But it was just me going insane.