[BUG] Unable to run executables due to missing DLL

[JMicheli]

This is likely a windows-specific problem (possibly related to my build environment).

After pulling down the latest develop, I am unable to run the executables generated by the project, including codegen and the stump_server executables. For example:

B:\Code\External\stump> cargo run --package codegen      
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.44s
     Running `target\debug\codegen.exe`
   Compiling prisma-cli v0.0.1 (B:\Code\External\stump\crates\prisma-cli)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.90s
     Running `B:\Code\External\stump\target\debug\prisma-cli.exe generate`
Prisma schema loaded from prisma\schema.prisma

✔ Generated Prisma Client Rust to .\src\prisma.rs in 4.97s

Prisma client has been generated successfully!
   Compiling stump_core v0.0.5 (B:\Code\External\stump\core)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 11.69s
     Running unittests src\lib.rs (target\debug\deps\stump_core-6553912f58d5025a.exe)
error: test failed, to rerun pass `-p stump_core --lib`

Caused by:
  process didn't exit successfully: `B:\Code\External\stump\target\debug\deps\stump_core-6553912f58d5025a.exe tests::codegen --ignored` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)

The same error occurs when starting the dev server using yarn dev:web.

Prior to this error, I had set up my environment to include the new dav1d dependency from #385 using vcpkg, and dav1d-sys was able to build correctly. I am wondering if the expected DLL might be related to this addition.

[aaronleopold]

I’ll try to get it running on my desktop this week to see what I can help to figure out. Offhand I don’t what could have gone amiss with your environment/the project on Windows, but almost certainly related to the dav1d requirements.

I'd say double check that any path variables are still set and accessible in your shell and try a good ol' cargo clean as surface level tests to start debugging

[wolffshots]

I think this could be related to the issue that I'm seeing with the Docker container:

stump  | /app/stump: error while loading shared libraries: libdav1d.so.7: cannot open shared object file: No such file or directory
stump exited with code 0

Looks like just a lil oversight in the Dockerfile in #385?
I'm currently just tryna get the Dockerfile building locally but have problems with MIGRATIONS_DIR not being defined in the prisma.rs model when calling cargo build --package stump_server --bin stump_server --release.
It's hard to tell what the specific issue is since the error message fills my terminal history with blank space followed by:

                                                      ^^^^^^^^^^^^ help: a static with a similar name exists: `DATAMODEL_STR`
175.6
175.6 error[E0425]: cannot find value `MIGRATIONS_DIR` in module `super`
175.6  --> core/src/prisma.rs:3:3446816
175.6   |
175.6 3 | ...igrate_deploy (super :: DATAMODEL_STR , super :: MIGRATIONS_DIR , & self . 0 . url ()) . await ; :: prisma_client_rust :: tokio :: tim...
175.6   |                                                     ^^^^^^^^^^^^^^ not found in `super`
175.6
175.6 error[E0425]: cannot find value `MIGRATIONS_DIR` in module `super`
175.6  --> core/src/prisma.rs:3:3447215
175.6   |
175.6 3 | ...e (migration , super :: DATAMODEL_STR , super :: MIGRATIONS_DIR , & self . 0 . url () ,) . await } pub fn _db_push (& self) -> :: pris...
175.6   |                                                     ^^^^^^^^^^^^^^ not found in `super`
175.6
175.6 For more information about this error, try `rustc --explain E0425`.
175.6 error: could not compile `stump_core` (lib) due to 5 previous errors

libdav1d does get installed to /usr/local/lib/x86_64-linux-gnu/libdav1d.so.7.0 successfully though.

[aaronleopold]

I think this could be related to the issue that I'm seeing with the Docker container:

stump  | /app/stump: error while loading shared libraries: libdav1d.so.7: cannot open shared object file: No such file or directory
stump exited with code 0

Looks like just a lil oversight in the Dockerfile in #385?

Yes, definitely something wrong in the Dockerfile relating to the AVIF addition. Perhaps that feature should have gone to experimental instead of nightly 😅

I'm currently eating lunch, I can try to mess around with the Dockerfile but my gut is telling me the .so file just needs to be copied over to the final layer and/or we just need to manually set the SYSTEM_DEPS_DAV1D_LIB env var (see https://github.com/rust-av/dav1d-rs?tab=readme-ov-file#overriding-the-dav1d-library)

I'm currently just tryna get the Dockerfile building locally but have problems with MIGRATIONS_DIR not being defined in the prisma.rs model when calling cargo build --package stump_server --bin stump_server --release. It's hard to tell what the specific issue is...

Did you run cargo prisma generate --schema ./core/prisma/schema.prisma before attempting to build the image? This is likely a separate issue, the prisma generation is unrelated to the AVIF additions.

[wolffshots]

Did you run cargo prisma generate --schema ./core/prisma/schema.prisma before attempting to build the image? This is likely a separate issue, the prisma generation is unrelated to the AVIF additions.

Yessir, I'll fiddle with it some more myself but you're probably right that it's a separate issue (possibly something related to Brendonovich/prisma-client-rust#195 but I'm not sure)

In the meantime for libdav1d.so.7.0 not being found I made these quick hacks to get round it: https://github.com/wolffshots/stump/blob/80450fb085394ec969d73ff48761437d9ce82258/docker/Dockerfile#L55

[aaronleopold]

The absolute path shouldn't necessarily be a problem, there is a bash script ran before compilation which swaps out the paths (see here and there)

[aaronleopold]

In a roundabout way, this will be fixed by #409

[aaronleopold]

@JMicheli I am going to close this out since I reverted the AVIF/dav1d work