The typical way to bundle libraries with an executable is to do a static compilation. That means that you have to distribute the source code of other libraries within yours and compile it as a part of your build. I don't like having other peoples' source code in my repo, so that wasn't acceptable
The next thought was to use '.a' files that exist in library directories on the OS. That almost works except that I couldn't find any way to get VS to link against MinGW .lib.a files. This approach also made me realize I don't want to change the build system significantly.
In the end, the best way to distribute an executable without any preexisting dependencies is to ship it with the shared libraries.
One of the hardest things was to determine which files to distribute. Getting a (recursive) list of which libraries are needed is possible since those things are baked into ELF (linux executables) and PE (windows), but you end up with a really long list that includes stuff already bundled with operating systems.
So you have to figure out which libraries to distribute, and which libraries are on the operating system by default.
In Windows with MSYS, it's easy - assume everything in the /mingw64/bin folder (where all the DLLs go) that is used by the executable needs to be distributed
On OSX, just assume assume /usr/local is the directory for third party things since that's where Homebrew installs libraries. /System and /usr/lib are some of the defaults.
On Linux, /lib should be the folder where system libraries go. Unfortunately that doesn't work on Arch, but it does work on Ubuntu and probably most distros.