Simplify usage in different Linux environments
See original GitHub issueI’m going to write down issue, working-but-terrible solution and would like to ask more experienced people around here for better solution.
Issue
Linux binaries shipped with NuGet package are mostly unusable unless user have exactly the same environment as the one package was built in. Even if you install all the dependencies, you are most likely to end up with slightly different versions of your libraries and OpenCVSharpExtern
won’t work.
So, unless you are using exactly the same Ubuntu with exactly the same versions of packages as on CI server, it won’t work out of the box.
Working but problematic solution
Local environment
- Build OpenCV or install version 4.3.0 (if your package repos have newer versions).
- Follow build instructions from
README.md
and buildOpenCvSharpExtern
. - Rename it to
libOpenCvSharp
(without .so) and put file into/usr/lib
or make sureld
finds it some other way.
Debug with ldd
or just read exception (it will mention what dependency is missing) if you encounter problems.
Docker
Things become even more fun here. If you are hosting ASP .NET Core app inside docker linux container, the only way I found is to build OpenCvSharpExtern
in the container similar to production and then extract compilation result along with all dependencies.
- Dockerize your app as usual, use
mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic
as runtime image base. - Run your container with something that won’t constantly break because of OpenCV exceptions (so container doesn’t stop).
docker exec container_name bash
to get into the container.- Run all the neccessary
apt-get install ...
, build OpenCV 4.3.0, build OpenCvSharp and make sure both are installed into the container system (present somewhere in/usr/local/share/opencvsharp4/
or elsewhere). There are CI scripts in this repo that should help withapt-get
part. - Copy all these dependencies into the host system (using mounted volume, for example). I had to copy
/usr/local
,/usr/lib
and/lib/x86_64-linux-gnu
which turned out to be 1.2GiB. - Remove this experimental container (optional, probably done by
docker-compose
automatically). - Setup your
Dockerfile
to copy these files from host onto runtime container after build. - Also something like
ENV LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/share/opencv4/lib/:/usr/local/lib/:/lib/x86_64-linux-gnu/"
will probably be required. - Enjoy this process again when upgrade of OpenCV needed (or runtime upgraded, etc).
Questions
- Is it possible to build statically linked
libOpenCvSharpExtern.so
to embed all the dependent libs into it? It looks like it was successfully done for Windows, so I wonder if it is possible on Linux. - Is there a better solution for docker problem? Would you just automate
compiling OpenCV in production environment
steps on your CI server or there is better approach?
I’m fairly noob in either docker and magic of C++ compilation, sorry if I’m missing something obvious. Hope this helps someone or attracts answers with better solutions 😃
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:6
Top GitHub Comments
A bit better solution
@shimat Thanks for the dockerfile you mentioned in #953. I modified this file to create base image that builds environment for running apps that use
OpenCVSharp
with all necessary dependencies. Modified dockerfile uses Ubuntu 20 dotnet SDK as base image.It can be added to
docker-compose.yml
and then used asFROM opencvsharp_base
in dockerfiles, or pushed to custom docker registry, etc.Dockerized .NET project does not need any dependency aside from
OpenCVSharp4
, native binaries will be built inside docker.However, I’m yet to separate build environment from runtime here. To do so, one will need to copy OpenCV build output and libOpenCvSharp.so (these are currently installed directly into the container system using
make install
) and install all the necessary packages (runtime should have same versions of dependencies ad build environment).Guess that will be the next step but for now I don’t mind a bit bloated container 😃
Dockerfile itself:
Example
docker-compose.yml
:Example
Dockerfile
:This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.