STATUS_DLL_NOT_FOUND

[ilyvion]

>cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target\debug\foobar.exe`
error: process didn't exit successfully: `target\debug\foobar.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)

And here I was hoping this experience would be better than with the sdl2 crate, what with these two points being made by beryllium and fermium, respectively:

On Windows all necessary files are provided automatically by fermium, you don't need to do any special setup at all. Note that the default link style is dynamic, and so you will need to have SDL2.dll available to run the program. You can turn off default features and turn on static linking if you like, but this takes longer to build.

and

On Windows MSVC, this crate will "just work" all on its own. The necessary files are packaged into the crate and you don't need to do anything special. Windows is the platform for video games, so naturally gamedev library developers should make sure that gamedev libraries have top quality support on Windows. They absolutely shouldn't require you to get files and unpack them yourselves into a bunch of special directories and then use a custom build script, that would obviously just be a terrible user experience.

I got the application to work by manually going to C:\Users\alexs\.cargo\registry\src\github.com-1ecc6299db9ec823\fermium-0.1.4\win32-devel-files\VC\lib\x64 and copying SDL2.dll and SDL2.lib into my target\debug\ folder, which admittedly is somewhat better than having to "get files and unpack them yourselves into a bunch of special directories and then use a custom build script," but only just.

[Lokathor]

Well it says quite clearly that it dynamic links by default, I suppose I could also be more clear that you need SDL2.dll for a dynamic linked program to work.

You can also switch to a static linked build if you want.

[Lokathor]

It's very late my timezone but I'll keep this in mind for tomorrow.

[ilyvion]

For the heck of it, I tried switching to the link_static feature flag, and that gave me this output:

>cargo build
   Compiling fermium v0.1.4
error: failed to run custom build command for `fermium v0.1.4`

Caused by:
  process didn't exit successfully: `C:\Users\alexs\Documents\Projects\foobar\target\debug\build\fermium-211b4d1de98225b6\build-script-build` (exit code: 101)
--- stdout
use_bindgen_bin: false
link_dynamic: false
link_static: true
bind_SDL2_2_0_9: false
bind_SDL2_2_0_10: false
cargo:rustc-env=TARGET=x86_64-pc-windows-msvc
cargo:rustc-env=BIND_PATCH_LEVEL=8
running: "cmake" "C:\\Users\\alexs\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\fermium-0.1.4\\full-source\\SDL2-v2.0.10" "-G" "Visual Studio 16 2019" "-Thost=x64" "-Ax64" "-DSDL_SHARED=OFF" "-DSDL_STATIC=ON" "-DCMAKE_INSTALL_PREFIX=C:\\Users\\alexs\\Documents\\Projects\\foobar\\target\\debug\\bui
ld\\fermium-ec36c5624a91bf23\\out" "-DCMAKE_C_FLAGS= -nologo -MT -Brepro" "-DCMAKE_C_FLAGS_RELEASE= -nologo -MT -Brepro" "-DCMAKE_CXX_FLAGS= -nologo -MT -Brepro" "-DCMAKE_CXX_FLAGS_RELEASE= -nologo -MT -Brepro" "-DCMAKE_BUILD_TYPE=release"

--- stderr
thread 'main' panicked at '
failed to execute command: The system cannot find the file specified. (os error 2)
is `cmake` not installed?

build script failed, must exit now', C:\Users\alexs\.cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.42\src\lib.rs:861:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So... I gave up on that fairly quickly, because I'd rather copy in a DLL than have to deal with debugging the build of SDL2.

Anyway, my gripe was mainly that for something that harps on other libraries that "require you to get files and unpack them yourselves into a bunch of special directories and then use a custom build script," this library doesn't "just work" either, without either manually copying SDL2.dll or setting up a buildscript to do it.

Not that I mind too much having to do that or anything. It just didn't match the expectation that I felt was being set up by the text quoted in my OP.

[Lokathor]

Yes, I could also clarify that point as well.

So there's a few things I'm going to write down in the fermium readme:

• if you cargo install fermium then you get a program named fermium as part of that which will, if you run it, write the SDL2.dll into your current directory.
• static linking on windows requires cmake, that's expected. Once you have cmake nothing else should go wrong.

Honestly you're the first person ever to try using this without having talked to me about it on Discord first. So, thanks for being a guinea pig.

[Lokathor]

For fermium, I've made these changes https://github.com/Lokathor/fermium/commit/555030ccbbeadd1f55c6126943a6d55529180000

For beryllium, a big part of the problem is that it's not updated to the latest fermium. There's an open PR (https://github.com/Lokathor/beryllium/pull/105) that I can probably merge today actually, I'll leave a comment there asking if they're all set and then we can get that merged and published if so.

[Lokathor]

beryllium-0.3.0 is out now, so perhaps this will help your experience.

In addition to using the latest fermium, the biggest change is that the linking features now use more natural English names, so they're static_link and dynamic_link.

[Lokathor]

Oh, and please let me know if this resolves things or if I should continue to improve the documentation.

[ilyvion]

Well, after I got things up and running, I felt like I couldn't really get anywhere, since (as far as I could tell) I'm intending to write a small tile-based 2D game, and for that I need SDL_image and SDL_ttf and possibly other such friends, and I saw no support for that, so I moved on to trying other libraries.

Maybe I was too hasty and missed something, but given how minimalistic the examples are, I have a feeling it's not really supported. I realized I was looking for something a little more... game-engine like.

But yeah, the docs (for fermium) are a lot better now. I don't think I'd be confused or upset about the missing DLL error if it had been like it is now when I first came upon it.

[Lokathor]

Hmm, well I'd use the image and rusttype crates for stuff like that. As far as I'm aware they work just fine with SDL2 based windows and contexts. It's possible to also use SDL_image or SDL_ttf, but basically using C from Rust is actually a huge pain so personally I would advise people to keep the amount of C code in their build process to a minimum.

If you want a fuller game engine you should try ggez.

I'll close this up, but try out the rust gamedev discord if you want more chatting about stuff: https://discord.gg/smpTpSW