🔨 Fix docker dav1d shared library linking

[wolffshots]

Adding explicit linking to the process appears to fix the error that I was experiencing in Docker builds that I mentioned in #406:

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

The Dockerfile still does not build locally despite adding a step to generate prisma.rs because of this error but that seems to be a separate issue:

                                                      ^^^^^^^^^^^^ 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

[wolffshots]

This is just to appease the linting

[wolffshots]

This could probably be done a lot more elegantly and generically but this seems to work so I'd be interested to see how I could do it better

[aaronleopold]

I won't have time to test this until after work, but this won't account for arm64 builds

[wolffshots]

Yeah I'm happy to look at it again tomorrow to work out how to make it more generic (like using TARGETARCH or something). Defs just a hack for now to get it to work for me
If you have an idea of how to improve I'll get to it in the morning but it's late over here so gonna call it for this attempt

[wolffshots]

This change allows me to build locally for testing but I'm happy to revert if needing

[wolffshots]

I had to overwrite the entrypoint on my docker compose to get this to successfully run: entrypoint: ["/bin/sh", "-c", "echo '/usr/local/lib' >> /etc/ld.so.conf.d/mylibs.conf && ldconfig && /entrypoint.sh"] but I did get it to work with this branch!
Just gonna try with a modified entrypoint.sh quickly before I call it for the night

[wolffshots]

The change that I just pushed allowed me to just run the image without changing the entrypoint in my compose.yml and it appears to be up and running a-okay now 🥳

[wolffshots]

Note that I actually had to remove the prisma.rs text replacements because it was actually generated in the Dockerfile above so was already correct

[wolffshots]

COPY --from=builder /usr/local/lib /usr/local/lib <- this is necessary
COPY --from=builder /etc/ld.so.conf.d/mylibs.conf  /etc/ld.so.conf.d/mylibs.conf <- this can probs be removed because I do it in `entrypoint.sh` now

[aaronleopold]

@wolffshots I made a few changes, since nightly is broken I wanted to make sure at the very least a working image goes out sooner rather than later. I appreciate your fixes! I translated them slightly to work for the arm64 build and then tweaked the ldconfig to the final layer in order to omit having to add it in the entrypoint exec. I left your change to generate the prisma client in the docker file, mostly because I am curious how it performs. If it winds up having to download the engines each time, I'll likely revert it. Best case scenario, though, it makes it easier for folks like you to build the images locally without needing a rust environment setup 🙂

After some discussions on Discord, once this fix is merged I will likely revert the AVIF-specific additions until another time when a more batteries-included solution can be put together.

[wolffshots]

Great stuff! Glad to have been able to help and thanks for all the hard work

[aaronleopold]

I left your change to generate the prisma client in the docker file, mostly because I am curious how it performs. If it winds up having to download the engines each time, I'll likely revert it. Best case scenario, though, it makes it easier for folks like you to build the images locally without needing a rust environment setup 🙂

I had to remove it, with prisma generation it stalled after 4+ hours on the arm64 build. The build without it completed both amd64 and arm64 in just under 2 😅

But I added some parameters you can use to generate it in the docker build. You can do something like:

PLATFORMS='linux/amd64' TAG='local' RUN_PRISMA_GENERATE=true ./docker/build.sh

[wolffshots]

I had to remove it, with prisma generation it stalled after 4+ hours on the arm64 build. The build without it completed both amd64 and arm64 in just under 2 😅

Fair that makes sense

But I added some parameters you can use to generate it in the docker build. You can do something like:

PLATFORMS='linux/amd64' TAG='local' RUN_PRISMA_GENERATE=true ./docker/build.sh

Great stuff, that's all good by me