0

I want to make a text based adventure game for a friend, so everything requiered should be for example on a USB stick.

I know I have to include the libraries to the file, but how do I find the requiered and link them to the original gamefile.

In the moment I use these libraries:

#include <iostream>
#include <string>
#include <chrono>
#include <thread>
#include <atomic>
#include <condition_variable>

I looked online for the library files and didn't find them. I searched long and didn't any tutorial.

Im using gcc, visual studio code and on windows

Alan Birtles
  • 32,622
  • 4
  • 31
  • 60
ferdinandfish
  • 11
  • 1
  • 1
    All of the headers you show are part of *C++ standard library*. Good news: most compilers link standard library statically, which means it gets bundled together with your program automagically. Bad news: you have to actually compile for correct architecture and operating system of the target computer to have even a chance of it running correctly. Slightly good news: most PCs have x64 architecture, so it's just a matter of compiling for correct OS. – Yksisarvinen Jul 24 '23 at 15:30
  • Usually you need to ship/include/distribute/install your compilers runtime libraries + any other library you use (that you don't statically link). – Jesper Juhl Jul 24 '23 at 15:44
  • 2
    What OS? Every OS has its own rules and procedures for distributing a compiled program. – Drew Dormann Jul 24 '23 at 15:50
  • 2
    @Yksisarvinen most compilers i know of default to a shared standard library as it avoids problems when using shared libraries which also use the standard library – Alan Birtles Jul 24 '23 at 16:02
  • 1
    Which compiler are you using? You should consult its documentation for how to redistribute the necessary libraries – Alan Birtles Jul 24 '23 at 16:03
  • 1
    For msvc you need to install the redistributable. The good thing is since 2015 the same redistributable works for all new versions of msvc: [https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) – drescherjm Jul 24 '23 at 16:10
  • ***Im using gcc, visual studio code and on windows*** That is MinGW. If you followed the official [VCode MinGW instructions](https://code.visualstudio.com/docs/cpp/config-mingw) and used msys2 to install MinGW and are using `tasks.json` instead of code-runner you can modify your tasks to statically link the runtime with this answer: [https://stackoverflow.com/a/43402308/487892](https://stackoverflow.com/a/43402308/487892) – drescherjm Jul 24 '23 at 18:32
  • @Yksisarvinen In my experience, most compilers *do not* link the standard library statically. First of all it is not always possible, secondly, it may not be what the user wants. Dynamic linking is the default in my experience and you generally have to ship your compilers runtime libraries along with your executable. – Jesper Juhl Jul 30 '23 at 20:50

2 Answers2

1

You need to distribute a few .dlls alongside the executable, in the same directory.

ntldd -R my_program.exe will give you a list of DLLs. Out of those, ignore anything that's not in your compiler's bin directory (note that the paths printed by ntldd can be wrong if you have those DLLs in other directories in PATH; so ignore the paths and compare just the filenames).

On my MinGW distribution, this gives me libgcc??.dll, libstdc++??.dll, and libwinpthread??.dll.

#includes are not "libraries", see Is iostream a header or a library. They don't have one-to-one correspondence with the DLLs.

Out of the three DLLs above, libstdc++ is the entirety of the C++ standard library, libwinpthread is the low-level threading library libstdc++ uses under the hood, libgcc contains low-level utilities used by GCC, and the C standard library mostly resides in system-provided DLLs (either msvcrt.dll or ucrtbase.dll, depending on MinGW flavor; you don't need to ship those).

A static linking (via the -static flag) is also an option, which will give you a single self-contained .exe.

But eventually you'll run into the libraries with licenses that discourage static linking (LGPL forces you to share source if you link statically), and/or build systems that don't produce static libraries out of the box (e.g. OpenAL; which uses LGPL), so better not get used to it. Also allowing the user to update the libraries by themselves is a good idea.

HolyBlackCat
  • 78,603
  • 9
  • 131
  • 207
  • Why the downvote? If there's something wrong here, I can't fix it if I'm not aware of it. – HolyBlackCat Jul 25 '23 at 18:03
  • "You need to distribute a few .dlls alongside the executable, in the same directory" - The "in the same directory" bit is not strictly correct. The Runtime loader also looks elsewhere and this is also different with different OS's. – Jesper Juhl Jul 30 '23 at 20:47
  • 1
    @JesperJuhl *"The "in the same directory" bit is not strictly correct"* Yep. I wasn't going for formal correctness, just for a practical solution. I think there are no good alternatives either? (Installing DLLs in PATH can cause weird conflicts; are there any other approaches?). *"different with different OS's"* Mhm, OP said they use Windows. I don't want to get into the can of worms of explaining how to make Linux apps reasonably portable, and I don't know how things work on Mac at all. – HolyBlackCat Jul 30 '23 at 21:50
  • "are there any other ways?" - Static linking is an alternative (although not always an option). – Jesper Juhl Jul 30 '23 at 21:53
  • Making Linux executables portable is not really that big of a can of worms. You either use the system provided libraries or use your own provided ones and load them via the correct RPATH. It's usually not that big of a deal. (In my experience). – Jesper Juhl Jul 30 '23 at 21:56
  • @JesperJuhl Mhm, I mentioned static linking too. Regarding Linux - there's a few things to know, like: having to build on an older distribution than any ones you want to support; knowing which libraries to ship and which to use from the system; quirks like having to compare libstdc++ version at runtime against the system-provided one, and picking whatever is newer; and generally the proliferation of various packaging solutions and which to pick if any (appimage/flatpak/snap/etc) etc. – HolyBlackCat Jul 30 '23 at 22:06
  • 1
    Yeah, I know. It's not trivial, but it's not exactly impossible either. I tend to just bundle whatever I need with my app and load the libraries relative to my install directory. That avoids most issues. Not the way to go for an open source app of course, but for a commercial app it works just fine :) In any case; an upvote for your answer :) – Jesper Juhl Jul 30 '23 at 22:07
-2

You do not need to share those libraries with your friend if all your friend wants to do is run your game. Once you have finished your game, you compile it into an executable (eg. a .exe file in Windows) and all your friend has to do is run the executable.

If you were to use other third-party libraries, then you might have to include them as .dll files together with your executable. However this should not be the case with standard libraries.

Hope this helps.

Samuel AC
  • 1
  • 1
  • 2
    The compilers runtime libraries are usually needed unless you statically link them (which is not always possible and usually not the default). – Jesper Juhl Jul 24 '23 at 15:46
  • 2
    Also, you seem to assume a Windows environment, but it is not at all clear from the question whether that's a valid assumption. – Jesper Juhl Jul 24 '23 at 16:06