Possible g++ linker bug in Boost on Msys2

Question

I have already set up my Msys2 and installed mingw-w64-x86_64-boost on it.

I provided a minimal example of c++ with boost which I will build using the command g++ main.cpp -o main.exe -lboost_program_options-mt:

#include <boost/program_options.hpp>
#include <string>
#include <iostream>
namespace po = boost::program_options;
int main(int argc, char** argv) {
    // Arguments will be stored here
    std::string input;
    std::string output;
    
    // Configure options here
    po::options_description desc ("Allowed options");
    desc.add_options ()
        ("help,h", "print usage message")
        ("input,i", po::value(&input), "Input file")
        ("output,o", po::value(&output), "Output file");

    // Parse command line arguments
    po::variables_map vm;
    po::store (po::command_line_parser (argc, argv).options (desc).run (), vm);
    po::notify (vm);

    // Check if there are enough args or if --help is given
    if (vm.count ("help") || !vm.count ("input") || !vm.count ("output")) {
        std::cerr << desc << "\n";
        return 1;
    }
    std::cout << "The rest of the code will be here"; <- Indication that it is working
}

It compiles and links without logging an error when I ran the said command, but now when I try to run it, it just doesn't execute properly.

At the least, I was expecting to see the text The rest of the code will be here to be outputted to the console when I ran it as an indication that it is being executed, however it didn't output it:

I tried to debug it, but GDB itself can't debug it

This is what it looks like in the VSCode Debug Console:

Running a separate GBD on the command line:

---

With all of that said, I am assuming that this is a linker error given that the resulting executable is being outputted by the compiler. What are your thoughts regarding this problem?

Answer 1

Yooo! I fixed the issue.

I first tried to run it on a fresh virtual machine to cross out the possibility that this issue is caused by my current environment. Surprisingly enough, it worked perfectly fine on the virtual machine. Knowing that it only happens in my current environment, I did proceed to make the following changes ().

1. Complete reinstallation of msys2 in my system, (you can disregard this step because I'm pretty sure that step 2 is enough)
2. Moving up the priority of the msys2 path in the environment variables.

To do step 2 follow these steps (windows 10):

1. Search for "Edit environment variables for your account" in the search bar
2. Under "User variables" select variable "path" and click edit
3. Now, select the item for the bin path of the mingw on Msys2
4. Once you've selected it now, move up its priority as shown below.
5. Press ok, then restart the terminal, and it should work now