After running an @world update today I got a preserved-libs warning, which usually indicates a missing slot-operator dependency. !!! existing preserved libs: >>> package: dev-cpp/abseil-cpp-20240722.0 * - /usr/lib64/libabsl_base.so.2401.0.0 * - /usr/lib64/libabsl_city.so.2401.0.0 * - /usr/lib64/libabsl_debugging_internal.so.2401.0.0 * - /usr/lib64/libabsl_demangle_internal.so.2401.0.0 * - /usr/lib64/libabsl_examine_stack.so.2401.0.0 * - /usr/lib64/libabsl_graphcycles_internal.so.2401.0.0 * - /usr/lib64/libabsl_hash.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * - /usr/lib64/libabsl_int128.so.2401.0.0 * - /usr/lib64/libabsl_kernel_timeout_internal.so.2401.0.0 * - /usr/lib64/libabsl_log_globals.so.2401.0.0 * - /usr/lib64/libabsl_log_internal_check_op.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * used by /usr/lib64/vlc/plugins/stream_out/libstream_out_chromecast_plugin.so (media-video/vlc-3.0.21) * - /usr/lib64/libabsl_log_internal_format.so.2401.0.0 * - /usr/lib64/libabsl_log_internal_globals.so.2401.0.0 * - /usr/lib64/libabsl_log_internal_log_sink_set.so.2401.0.0 * - /usr/lib64/libabsl_log_internal_message.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * used by /usr/lib64/vlc/plugins/stream_out/libstream_out_chromecast_plugin.so (media-video/vlc-3.0.21) * - /usr/lib64/libabsl_log_internal_nullguard.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * - /usr/lib64/libabsl_log_internal_proto.so.2401.0.0 * - /usr/lib64/libabsl_log_sink.so.2401.0.0 * - /usr/lib64/libabsl_low_level_hash.so.2401.0.0 * - /usr/lib64/libabsl_malloc_internal.so.2401.0.0 * - /usr/lib64/libabsl_raw_logging_internal.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * - /usr/lib64/libabsl_spinlock_wait.so.2401.0.0 * used by /usr/lib64/libopencv_dnn.so.4.9.0 (media-libs/opencv-4.9.0-r2) * - /usr/lib64/libabsl_stacktrace.so.2401.0.0 * - /usr/lib64/libabsl_str_format_internal.so.2401.0.0 * - /usr/lib64/libabsl_strerror.so.2401.0.0 * - /usr/lib64/libabsl_string_view.so.2401.0.0 * - /usr/lib64/libabsl_strings.so.2401.0.0 * - /usr/lib64/libabsl_strings_internal.so.2401.0.0 * - /usr/lib64/libabsl_symbolize.so.2401.0.0 * - /usr/lib64/libabsl_synchronization.so.2401.0.0 * - /usr/lib64/libabsl_throw_delegate.so.2401.0.0 * - /usr/lib64/libabsl_time.so.2401.0.0 * - /usr/lib64/libabsl_time_zone.so.2401.0.0
It's not that simple. /usr/lib64/libopencv_dnn.so.4.9.0 shouldn't link to abseil at all. But (some) protobuf exposes the internal linkage to abseil-cpp. It doesn't happen with my local opencv-4.10. So I'll have to see what I have to backport.
It looks like this occurred after upgrading from dev-cpp/abseil-cpp-20240116.2-r4 to dev-cpp/abseil-cpp-20240722.0.
After rebuilding opencv, I see this in NEEDED.ELF.2: X86_64;/usr/lib64/libopencv_dnn.so.4.9.0;libopencv_dnn.so.409;/usr/lib64;libopencv_imgproc.so.409,libprotobuf.so.27.2.0,libopencv_core.so.409,libabsl_log_internal_check_op.so.2407.0.0,libabsl_log_internal_message.so.2407.0.0,libabsl_log_internal_nullguard.so.2407.0.0,libabsl_hash.so.2407.0.0,libabsl_spinlock_wait.so.2407.0.0,libabsl_raw_logging_internal.so.2407.0.0,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6,ld-linux-x86-64.so.2;x86_64
This is with dev-libs/protobuf-27.2.
In case USE flags matter: media-libs/opencv-4.9.0-r2::gentoo was built with the following: USE="contrib contribdnn eigen features2d ffmpeg jpeg opengl png python qt5 qt6 tiff -atlas -contribcvv -contribfreetype -contribhdf (-contribovis) -contribsfm -contribxfeatures2d -cuda -cudnn -debug -dnnsamples -doc -examples -gdal -gflags -glog -gphoto2 -gstreamer -gtk3 -ieee1394 -jasper -java -jpeg2k -lapack -mkl -non-free -opencl -opencvapps -openexr -openmp -quirc -tbb -tesseract -test -testprograms -v4l -vaapi -vtk -webp -xine" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="popcnt sse sse2 sse3 -avx -avx2 -avx512f -f16c -fma3 -sse4_1 -sse4_2 -ssse3" PYTHON_TARGETS="python3_12 -python3_10 -python3_11" VIDEO_CARDS="-intel" dev-libs/protobuf-27.2::gentoo was built with the following: USE="libprotoc protobuf protoc zlib -conformance -emacs -examples -libupb -test" ABI_X86="64 -32 -x32"
For me it is media-sound/mixxx-9999 and dev-util/android-tools-35.0.1 Both ebuilds depend on dev-libs/protobuf but not on abseil-cpp. Same for vlc as we can see. So what do we do? Add deps to these ebuilds? A virtual ebuild? eclass?
(In reply to jospezial from comment #6) Two possible solutions: 1. Packages using protobuf stop linking with abseil-cpp libraries. 2. Packages using protobuf add a dependency on abseil-cpp. I don't know enough about protobuf to say what is possible here.
(In reply to Mike Gilbert from comment #7) > (In reply to jospezial from comment #6) > > Two possible solutions: > > 1. Packages using protobuf stop linking with abseil-cpp libraries. > 2. Packages using protobuf add a dependency on abseil-cpp. > > I don't know enough about protobuf to say what is possible here. Well... (In reply to Paul Zander from comment #1) > It's not that simple. > > /usr/lib64/libopencv_dnn.so.4.9.0 shouldn't link to abseil at all. But > (some) protobuf exposes the internal linkage to abseil-cpp. It doesn't > happen with my local opencv-4.10. So I'll have to see what I have to > backport. This is saying that when you use pkg-config / cmake find_package() and look up protobuf, it adds the recursive compile/link arguments for abseil-cpp as well, then includes abseil types in the headers and stuff. So there's really nothing for it other than to add abseil as a dependency I suppose.
See https://bugs.gentoo.org/912819#c4. I think we need to do virtual/protobuf.
parona: mind summarising your findings/our conclusions from a while ago?
(In reply to Eli Schwartz from comment #8) > So there's really nothing for it other than to add abseil as a dependency I > suppose. Yeah, even if it's not something it looks for itself, when a package links with something (even indirectly through pkg-config) it should always be added imo. Some devs argue against this but when that furthermore needs := it becomes simply broken not to. ...and iwdevtools can warn about this so it's easy to pickup even if you don't see it in the build system: * VDB: detected possibly incorrect RDEPEND (media-libs/opencv-4.9.0-r2) * app-arch/bzip2 < * > dev-cpp/abseil-cpp:= The flakiness in whether absl gets used or not in this seem seems like another thing issue though. virtual can be an option but not convinced it's worth the added trouble in all of these cases, albeit it does allow to change the dependency set depending on the version without updating all revdeps (e.g. if it stopped injecting abseil-cpp we're now left with a lot of worthless deps when could be updating the virtual instead, albeit the virtual may be worthless then and need removal).
(for a cleaner future solution, feels a bit similar to the xorg-proto problem and the talk to have packages be able to declare dependencies for packages that depend on them, may it be extra headers for DEPEND or binded deps for RDEPEND)
My argument for a virtual is not a purity one, it's that you end up with breakage where protobuf depends on abseil's ABI (!) and you need to rebuild protobuf after rebuilding abseil. You have to trigger the rebuilds in the right order as well after that (i.e. everything depending on protobuf+abseil needs to be rebuilt after abseil then protobuf).
This showed up for me earlier with updating abseil, not yet having merged the protobuf PR, mosh being broken at runtime, then after having merged the protobuf PR (-> protobuf is rebuilt), mosh starts to work again even if mosh can't be rebuilt for other reasons.
Ah yes, I could imagine that being an issue in this particular case. I was more thinking generally (e.g. gtk).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=323b06cc80581deda4603d8bd70fd25cf79e49b2 commit 323b06cc80581deda4603d8bd70fd25cf79e49b2 Author: Paul Zander <negril.nx+gentoo@gmail.com> AuthorDate: 2024-11-02 11:50:31 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-11-05 02:02:32 +0000 media-libs/opencv: refactor abseil lookup #939076 Linking against abseil-cpp depended on protobuf exporting all abseil-cpp libraries via protobuf::libprotobuf public libraries. Explicitly finding abseil ourselves removes the need for that. Closes: https://bugs.gentoo.org/939076 Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> ...-4.10.0-dnn-explicitly-include-abseil-cpp.patch | 39 ++++++++++++++++++++++ media-libs/opencv/opencv-4.10.0.ebuild | 7 +++- 2 files changed, 45 insertions(+), 1 deletion(-)
