Feature: Allow statically linking libstdc++ in the build.rs

[donicrosby]

When building a binary for Windows or other hosts that have different libstdc++ implementations it would be nice to be able to statically link libstdc++ for the library so that final programs don't need to ship the shared libs or the dlls for windows.

[crumblingstatue]

I'm using the link-cplusplus crate for linking the C++ standard library, but it doesn't seem to have a static option.

[donicrosby]

I have been playing around with how to do this, I'll probably make a PR hopefully some time this week. It's really making sure you have the correct libstdc++.a for the compiler

[crumblingstatue]

Just make sure that you don't change how dynamic linking works. So this libstdc++ specific code should only happen when static linking is requested.

[NuriYuri]

Necro post but it seems that you cannot use CSFML statically any way (because SFML is built in C++). With the MSVC build of SFML I just need OpenAL and the SFML dlls (nothing related to stdc++).

I've though a bit about this whole bindgen stuff but it seems that some stuff SFML is doing is not supported and will never be (because that's way to complex to handle, inline, template etc...)

Regarding the fact your need to bundle the dlls on Windows is not really a big issue, almost all programs do it, the cool thing with Windows is that you don't have to specify a LD_LIBRARY_PATH, by default it looks into executable's current folder and if your executable is specifying dependent manifest you're able to move the dlls into a sub folder.

Regarding the environment setup. On my project I added a deps folder which holds SFML-2.6 binaries in a folder (extraction of the zip in a folder of the same name) and my workspace's settings.json contains:

  "rust-analyzer.cargo.extraEnv": {
    "SFML_INCLUDE_DIR": "${workspaceFolder}\\deps\\SFML-2.6.0\\include",
    "SFML_LIBS_DIR": "${workspaceFolder}\\deps\\SFML-2.6.0\\lib"
  },
  "rust-analyzer.runnables.extraEnv": {
    "SFML_INCLUDE_DIR": "${workspaceFolder}\\deps\\SFML-2.6.0\\include",
    "SFML_LIBS_DIR": "${workspaceFolder}\\deps\\SFML-2.6.0\\lib"
  }

I also have this setup.bat script so I can do deps\setup when I need to use cli (cargo build --release);

SET SFML_INCLUDE_DIR=%cd%\deps\SFML-2.6.0\include
SET SFML_LIBS_DIR=%cd%\deps\SFML-2.6.0\lib

(Unfortunately it's still required to copy the DLLs but that's a thing you do once and less likely need to do later).

[crumblingstatue]

I've been experimenting with techniques to statically link libstdc++ (and libgcc) on Linux on the vendored-sfml branch, but so far nothing worked. In particular, any form of -static-libgcc and -static-libstdc++ flags seem to get ignored. But if anyone manages to make it work, let me know.

[crumblingstatue]

I believe as much as possible this is supported on Windows MSVC now, with the latest changes. However supporting it for GNU seems infeasible, but if anyone thinks otherwise, feel free to open another issue or pull request.