ImportError: libGL.so.1: cannot open shared object file: No such file or directory

[yeldarby]

Search before asking

• I have searched the Inference issues and found no similar bug report.

Bug

If you install inside of Docker you need to ensure you have additional dependencies otherwise you get an error.

Ideally we should not require these (I think there's a headless version of cv2 we could use). Alternatively maybe we could catch this error and recommend the solve: apt-get update && apt-get install ffmpeg libsm6 libxext6 -y

Environment

root@C.10017133:/$ pip freeze | grep inference
inference-cli==0.9.15
inference-gpu==0.9.15
inference-sdk==0.9.15
root@C.10017133:/$ 

pytorch/pytorch:2.2.0-cuda12.1-cudnn8-devel docker with after running pip install inference-gpu

Minimal Reproducible Example

root@C.10017778:~$ inference benchmark python-package-speed -m "yolov8n-640"
Traceback (most recent call last):
  File "/usr/local/bin/inference", line 5, in <module>
    from inference_cli.main import app
  File "/usr/local/lib/python3.10/dist-packages/inference_cli/main.py", line 6, in <module>
    import inference_cli.lib
  File "/usr/local/lib/python3.10/dist-packages/inference_cli/lib/__init__.py", line 8, in <module>
    from inference_cli.lib.container_adapter import (
  File "/usr/local/lib/python3.10/dist-packages/inference_cli/lib/container_adapter.py", line 10, in <module>
    from inference_cli.lib.utils import read_env_file
  File "/usr/local/lib/python3.10/dist-packages/inference_cli/lib/utils.py", line 5, in <module>
    from supervision.utils.file import read_yaml_file
  File "/usr/local/lib/python3.10/dist-packages/supervision/__init__.py", line 9, in <module>
    from supervision.annotators.core import (
  File "/usr/local/lib/python3.10/dist-packages/supervision/annotators/core.py", line 4, in <module>
    import cv2
  File "/usr/local/lib/python3.10/dist-packages/cv2/__init__.py", line 181, in <module>
    bootstrap()
  File "/usr/local/lib/python3.10/dist-packages/cv2/__init__.py", line 153, in bootstrap
    native_module = importlib.import_module("cv2")
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
root@C.10017778:~$ D

Additional

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!

[PawelPeczek-Roboflow]

I've taken a look and not found an elegant solution for the problem. The PR opened by @hvaria suggest switch to headless opencv for CLI completely. The problems are the following:

• there are installations where we resolve both cli requirements and core lib requirements - in presence of both, without libGL.so.1 being provided - even if there is no cv2.imshow(...) invocation - we have error - which would be the case in @yeldarby example (all libs installed) even with the change
• CLI uses visualisation (inference infer command) - so we cannot completely eliminate standard OpenCV

We could probably do the following (tradeoffs, pros and cons that I see outlined)

• have headless as a base requirement and have [desktop] extras in all libs and install standard cv on clients wish. Drawbacks:
  • people usually by default would try our lib in GUI-env - and would probably even use cv.imshow(...) to visualise, so asking them for additional effort may degenerate developer-experience
• catching the error would be possible - may be not necessarily elegant, but could work. The core of that problem is not the fact that one cannot install standard CV without GUI - it's rather the fact of additional shared libs being required - so I am leaning towards that approach, if we cannot apply the next option
• it seems that this problem could be completely avoided - and probably that should be done. If you analyse the series of imports leading to this error - you will discover that in inference_cli.lib.utils we import opencv through supervision (btw - it's headless by default and drags this into dependencies we install with inference) which is only used there due to read_yaml_file(...) util - which can be re-implemented or import could be pushed to another module. In long run - we shall think of developing CLI modules to be more command-oriented - to isolate potential domains of errors

[hvaria]

I fully agree with your analysis and the outlined approach to navigate these complexities.