conda-forge/opencv-feedstock

Compatibility of recent opencv builds with older Ubuntus e.g. 20.04

igozali opened this issue · 5 comments

Comment:

I was wondering if there's a good way to install more recent opencv packages from conda-forge on older Ubuntu versions e.g. 20.04? The primary issue seems to be the glibc version, where I would be encountering these kinds of issues:

2023-05-09T15:20:11.5582410Z /usr/bin/ld: /home/user/conda-envs/foo/lib/libQt5Core.so.5: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
2023-05-09T15:20:11.5583424Z /usr/bin/ld: /home/user/conda-envs/foo/lib/libopencv_core.so.4.5.5: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
2023-05-09T15:20:11.5584340Z /usr/bin/ld: /home/user/conda-envs/foo/lib/libQt5Widgets.so.5: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
2023-05-09T15:20:11.5585233Z /usr/bin/ld: /home/user/conda-envs/foo/lib/libQt5Core.so.5: undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'

The above happens with this version of opencv:

libopencv                                 4.5.5  py310hcb97b83_13         conda-forge/linux-64     Cached
opencv                                    4.5.5  py310hff52083_13         conda-forge/linux-64     Cached
py-opencv                                 4.5.5  py310hfdc917e_13         conda-forge/linux-64     Cached

In Ubuntu 20.04, the highest glibc version we can install from apt is 2.31 (without resorting to tricks like compiling our own glibc and patchelf shenanigans).

Here's some mamba info printouts from my system:

2023-05-09T14:53:32.2004430Z      active environment : None
2023-05-09T14:53:32.2004852Z             shell level : 0
2023-05-09T14:53:32.2005835Z        user config file : /home/user/.condarc
2023-05-09T14:53:32.2006475Z  populated config files : /home/user/conda-base/miniconda-py38_4.9.2/.condarc
2023-05-09T14:53:32.2006899Z           conda version : 23.3.1
2023-05-09T14:53:32.2007347Z     conda-build version : not installed
2023-05-09T14:53:32.2007702Z          python version : 3.8.16.final.0
2023-05-09T14:53:32.2008122Z        virtual packages : __archspec=1=x86_64
2023-05-09T14:53:32.2008490Z                           __glibc=2.31=0
2023-05-09T14:53:32.2008813Z                           __linux=5.4.0=0
2023-05-09T14:53:32.2009092Z                           __unix=0=0
2023-05-09T14:53:32.2009639Z        base environment : /home/user/conda-base/miniconda-py38_4.9.2  (writable)
2023-05-09T14:53:32.2010255Z       conda av data dir : /home/user/conda-base/miniconda-py38_4.9.2/etc/conda
2023-05-09T14:53:32.2010660Z   conda av metadata url : None
2023-05-09T14:53:32.2010978Z            channel URLs : 
2023-05-09T14:53:32.2011470Z           package cache : /home/user/.conda/pkgs
2023-05-09T14:53:32.2012516Z        envs directories : /home/user/conda-envs
2023-05-09T14:53:32.2014180Z                           /home/user/.conda/envs
2023-05-09T14:53:32.2014597Z                platform : linux-64
2023-05-09T14:53:32.2015189Z              user-agent : conda/23.3.1 requests/2.29.0 CPython/3.8.16 Linux/5.4.0-64-generic ubuntu/20.04.3 glibc/2.31
2023-05-09T14:53:32.2015573Z                 UID:GID : 6782739:100
2023-05-09T14:53:32.2015915Z              netrc file : None
2023-05-09T14:53:32.2016234Z            offline mode : False

The use case for this is if we're operating on a cluster computing system where we don't easily have root access, upgrading the Ubuntu OS (to get a newer glibc) is a rather slow process and we often have to install things in userspace, e.g. the solution provided by this gist: https://gist.github.com/michaelchughes/85287f1c6f6440c060c3d86b4e7d764b

Another thing I was wondering: since conda knows the version of the system's glibc, is it possible to have the opencv package build process incorporate the glibc version in the version compatibility checks.

Those errors are related to C++ symbols, so libstdcxx, not glibc . Are you sure that your process is loading conda-forge's libstdcxx and not for some reason the system one?

My bad, thanks for the clarification and suggestion. We've actually been using system libstdcxx, glibc to build additional Python extensions on top of the shared libraries we download from conda.

In the past, I've wanted to use the build toolchain that comes from the conda environment instead of system build toolchain, but I had some issues because conda's build toolchain is configured as a cross-compiler (asked in Gitter) as well.

I will try to pick up libstdcxx from conda-forge and see how that goes!

Seems to work, I will close the issue. Thanks again for the help!