Bugzilla – Bug 1218630
Cannot use apps with dependencies on libqt5-qtwebengine.
Last modified: 2024-01-11 06:08:43 UTC
ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20240107" libqt5-qtwebengine : 5.15.16-3.1 kontact : 23.08.4-1.1 kmail : 23.08.4-1.1 kchmviewer : 8.0-3.4 opensuse-welcome : 0.1.9+git.35.4b9444a-1.2 recoll : 1.36.2-5.4. [Phenomenon] $ kontact kontact: symbol lookup error: /lib64/libQt5WebEngineCore.so.5: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60.3_SUSE $ kmail --view mark/denki/220 kmail: symbol lookup error: /lib64/libQt5WebEngineCore.so.5: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60.3_SUSE $ kchmviewer kchmviewer: symbol lookup error: /lib64/libQt5WebEngineCore.so.5: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60.3_SUSE $ opensuse-welcome opensuse-welcome: symbol lookup error: /lib64/libQt5WebEngineCore.so.5: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60.3 _SUSE $ recoll recoll: symbol lookup error: /lib64/libQt5WebEngineCore.so.5: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60.3_SUSE [Cause] libqt5-qtwebengine is built with ffmpeg 6.0, but the Tumbleweed standard package for FFmpeg is ffmpeg-6.0.1, which causes the above errors. In fact, building and installing ffmpeg-6.0 or building and installing libqt5-qtwebengine without-ffmpeg do solve the problem. That is, if libqt5-qtwebengie built with ffmpeg-6.0.1 is provided, I believe the problem is complete.
> libqt5-qtwebengine : 5.15.16-3.1 The latest version of this in the official TW repo is libqt5-qtwebengine-5.15.16-1.2.x86_64. This is most likely coming from a 3rd party repo? > libqt5-qtwebengine is built with ffmpeg 6.0, but the Tumbleweed standard package for FFmpeg is ffmpeg-6.0.1, which causes the above errors. If this was the case, TW would be too broken for openQA to pass and the snapshot would not have been published.
> The latest version of this in the official TW repo is libqt5-qtwebengine-5.15.16-1.2.x86_64. This is most likely coming from a 3rd party repo? Sorry, this is based on the src.rpm of 5.15.16-1.2 I built without-ffmpeg to use recoll. libqt5-qtwebengine : 5.15.16-3.1 > If this was the case, TW would be too broken for openQA to pass and the snapshot would not have been published. Are you saying that you've actually tried kontact, kmail, and opensuse-welcome, etc.? Mine is pure tumbleweed.
(In reply to Masaru Nomiya from comment #2) > > The latest version of this in the official TW repo is libqt5-qtwebengine-5.15.16-1.2.x86_64. This is most likely coming from a 3rd party repo? > > Sorry, this is based on the src.rpm of 5.15.16-1.2 I built without-ffmpeg to > use recoll. > > libqt5-qtwebengine : 5.15.16-3.1 > > > If this was the case, TW would be too broken for openQA to pass and the snapshot would not have been published. > > Are you saying that you've actually tried kontact, kmail, and > opensuse-welcome, etc.? > Mine is pure tumbleweed. Not just me, also openQA: https://openqa.opensuse.org/tests/3854139#step/finish_desktop/1 The expected symbol is provided here: 434e77a82037:/ # readelf -sW /usr/lib64/libavformat.so.60.3.100 | grep av_stream_get_first_dts 649: 0000000000197f20 8 FUNC GLOBAL DEFAULT 15 av_stream_get_first_dts@@LIBAVFORMAT_60.3_SUSE 434e77a82037:/ # rpm -qf /usr/lib64/libavformat.so.60.3.100 libavformat60-6.0.1-2.2.x86_64
You've got something basically wrong． In libqt5-qtwebengine-5.15.16-1.2.src.rpm, qtwebengine-ffmpeg5.patch is included, but this patch is valid up to ffmpeg-6.0． In ffmpeg-6.0.1, the following part of this patch causes error occurs. diff --git a/src/3rdparty/chromium/media/filters/audio_file_reader.cc b/src/3rdparty/chromium/media/filters/audio_file_reader.cc index cb81d92..bd73908 100644 --- a/src/3rdparty/chromium/media/filters/audio_file_reader.cc +++ b/src/3rdparty/chromium/media/filters/audio_file_reader.cc @@ -85,7 +85,7 @@ bool AudioFileReader::OpenDemuxer() { } bool AudioFileReader::OpenDecoder() { - AVCodec* codec = avcodec_find_decoder(codec_context_->codec_id); + const AVCodec* codec = avcodec_find_decoder(codec_context_->codec_id); if (codec) { // MP3 decodes to S16P which we don't support, tell it to use S16 instead. if (codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P) If you look at the source code of ffmpeg-6.0.1, you will see what I mean. If you don't make a patch for ffmpeg-6.0.1, you won't be able to build libqt5-qtwebengine under the with-ffmpeg condition, at all! Besides, the symbols should be compared between the libavformat of ffmpeg-6.0 and the libavformat of ffmpeg-6.0.l. Regards && Good Night
(In reply to Masaru Nomiya from comment #4) > You've got something basically wrong． > > In libqt5-qtwebengine-5.15.16-1.2.src.rpm, qtwebengine-ffmpeg5.patch is > included, but this patch is valid up to ffmpeg-6.0． > In ffmpeg-6.0.1, the following part of this patch causes error occurs. In OBS it built fine against 6.0.1: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Rebuild/libqt5-qtwebengine/standard/x86_64 > Besides, the symbols should be compared between the libavformat of ffmpeg-6.0 and the libavformat of ffmpeg-6.0.l. No, between the lib that needs it and the lib that provides it. I demonstrated that in TW they match while on your system they do not, leading to the error. There are no other reports of this issue, so it's most likely constrained to your system. I suspect you have a custom build of ffmpeg installed instead of the system provided binaries.
> I suspect you have a custom build of ffmpeg installed instead of the system provided binaries. You Great!! The reason was that I built with --enable-cuda added. I deeply apologize for the inconvenience. m(_ _)m
(In reply to Masaru Nomiya from comment #6) > > I suspect you have a custom build of ffmpeg installed instead of the system provided binaries. > > You Great!! > > The reason was that I built with --enable-cuda added. That on its own shouldn't actually break API/ABI, but you'd have to make sure to build with the same (relevant) options and patches as the system package. In this specific case you were probably missing https://build.opensuse.org/package/view_file/openSUSE:Factory/ffmpeg-6/ffmpeg-chromium.patch?expand=1. > I deeply apologize for the inconvenience. m(_ _)m NP. If you replace any system libs, please mention that in the report as it can be relevant.
> That on its own shouldn't actually break API/ABI, but you'd have to make sure to build with the same (relevant) options and patches as the system package. One more thing: I added --enable-libopencv. Here, opencv refers to opencv3. I reviewed the SPEC file, and I think I just added the 2 build options.... Except for ffmpeg, I only build Multimedia-related applications, and have been intended to avoid touching system libraries.... Is there still something wrong with this?
(In reply to Masaru Nomiya from comment #8) > > That on its own shouldn't actually break API/ABI, but you'd have to make sure to build with the same (relevant) options and patches as the system package. > > One more thing: I added --enable-libopencv. > Here, opencv refers to opencv3. > > I reviewed the SPEC file, and I think I just added the 2 build options.... > > Except for ffmpeg, I only build Multimedia-related applications, and have > been intended to avoid touching system libraries.... > > Is there still something wrong with this? No, it's perfectly fine to customize your system any way you want. I recommend though to not overwrite files provided by packages and install to e.g. /usr/local. That way it's easy to check whether an issue is caused by such a custom build or not.
I've touched the system a lot before moving to Tumbleweed, but since moving to Tumbleweed, I've come to think that the right way to use Linux is to accept it for what it is....... In any case, when I do something, I'll do it in /usr/local as advised. Many Thanks.
(In reply to Masaru Nomiya from comment #10) > I've touched the system a lot before moving to Tumbleweed, but since moving > to Tumbleweed, I've come to think that the right way to use Linux is to > accept it for what it is....... Or even better: Try to get improvements upstream, so that all users can benefit.
I always raise questions upstream if there is a problem. This time, I mistakenly thought it was an openSUSE's problem and raised it to bugzilla. Upstream, I sometimes communicate with the maintainer of openSUSE, so it is very useful. I am a member of many development mailing lists, but KDE-related mails are too much for me to manage, so I unsubscribed the lists. Thanks.