0

This code will run on your machine, but not on mine:

#include <iostream>
#include <vector>

using namespace std;

int main(){

    vector<int> vv;

    vv.push_back(1); //<--- without this, everything works

    cout << "X\n";

    return 0;
}

The reason, is that it appears my windows machine is missing a (or has a conflicting) specific DLL related to Vectors which is causing my other projects to crash without a report if I use vectors.

However, what's even more entertaining is:

  1. If I comment the push back line, it executes normally without a crash.
  2. Other programs work completely fine as long as they avoid vector, as in using list or an array.

GDB Reports "During startup program exited with code 0xc0000139." Which means it couldn't find the dll it wants. Looking through the dependencies of my executable with Dependency Walker is rather inconclusive, I can't tell what is wrongly missing and what is normally missing among the dlls.

It could also be that there is a second dll that is conflicting with it (like I downloaded two different compilers). Investigating with Process Monitor informs me that instead of using the MinGw64 files located in the MSYS2 folder, the process uses the dlls inside of my ProgramFiles/Git/mingw64/bin location.

So it could be an issue? But Process Monitor doesn't tell me why or what is causing the process to exit unsuccessfully...

How would I get Windows to use the dlls in MSYS2 instead of the Git location? The solution that the post I linked above says is to remove the "erroneous dlls." But I can't just remove dlls that git uses?

Also, how am I guaranteed that switching to the dlls within MSYS2 is going to fix my problem? I just want to use vectors lol, how hard does this have to be?

Other solutions include leaving this spyware infested OS and enter the world of Linux, but that's a huge change.

HMM
  • 27
  • 3
  • Maybe you should ship your compilers runtime libraries with your program..? Not hard; just something you need to do whenever you build a C++ program. – Jesper Juhl Aug 02 '22 at 18:33
  • Yes make sure that you put the runtime from your current compiler in the same folder as the executable when you install it on some other system. Having a different version of the same dll in some folder of the PATH environment variable will cause this type of problem. – drescherjm Aug 02 '22 at 18:34
  • ***So it could be an issue?*** Yes definitely – drescherjm Aug 02 '22 at 18:40
  • 1
    Or, build the project statically so the runtime libraries are built into the final executable, then you won't have external DLLs that need to be deployed with it – Remy Lebeau Aug 02 '22 at 18:48
  • @RemyLebeau That can be *really hard* to do correctly. Just saying. – Jesper Juhl Aug 02 '22 at 18:53
  • @JesperJuhl depends in the compiler. I've been deploying statically-built programs for over 20 years without trouble – Remy Lebeau Aug 02 '22 at 18:57
  • @RemyLebeau I'm not saying it is impossible. I'm just saying it it often fraught with danger. If you know what you are doing it can be done; sure. If you are not an expert it can be quite difficult. – Jesper Juhl Aug 02 '22 at 19:00

0 Answers0