Bug 1729806
Summary: | pulseaudio-12.99.1 breaks qtwebengine build | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ömer Fadıl Usta <omerusta> |
Component: | qt5-qtwebengine | Assignee: | Rex Dieter <rdieter> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 31 | CC: | arun, kde-sig, kevin, lpoetter, rdieter, tanuk, wtaymans |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-13 18:24:23 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ömer Fadıl Usta
2019-07-14 23:43:59 UTC
Bug report done on both upstreams ( QT and pulseaudio ) : qt : https://bugreports.qt.io/browse/QTBUG-77037 pulseaudio : https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/707 on qt bug report there is a comment about solution : Kirill Burtsev added a comment - 6 minutes ago gn_args += link_pulseaudio fixes the issue for me, but in this case pulseaudio is used in a different manner: direct linking instead of dlopen on library with stub with function signatures (event then pulse/pulseaudio.h is still included in stubs). Why dynamic load and symbols resolution are the default in chromium? Appears the context here is limited to qtwebengine component, adjusting summary to match Per upstream bug, "Maybe one relatively painless solution would be to import the old (pulse) headers into the Qt source tree. Their reimplementation could then use those old headers, and they could handle header updates on their own schedule." we could also implement that workaround in qt5-qtwebengine packaging. I'll see how much effort that will be. triaging to qt5-qtwebengine component, to work on suggested workaround of using bundled pulse headers Using bundled headers for a system library strikes me as a bad idea, as mismatches between the header and the library can easily lead to startup-time (runtime linker) or runtime errors. If you ask me, I would vote for just using the link_pulseaudio option instead, if that also fixes the issue. I don't see the point of dlopening it. In fact, QtWebEngine has already been hit by such a header vs. library mismatch in the past. Remember the re2 saga, where the unbundling was not fully working and we had to actually copy the system headers over the bundled ones manually? Out of curiosity, is there a reason for distros to not directly link? (I can see why a standalone build would dlopen() as you don't know what's available on the system) Some people hate PulseAudio with a vengeance and don't want to install even the libraries. But there are other packages linked against the library too, so it is doubtful that they would be able to avoid it anyway. I think we should just link PulseAudio instead of dlopening it. As far as I'm aware, the PA linking/dlopen issue isn't generally a distro question, that's simply the qtwebengine (and chromium?) upstream default behavior. In fact, until Kevin brought it up, I was not aware of this. That said, from a fedora/distro perspective, linking is generally preferable to dlopen (for several reason). I'll look into implementing that. Fwiw, doing some local/scratch-build testing, appears the header hack/workaround is still required when using CONFIG+=link_pulseaudio. not sure if that's expected or not. Apparently adding CONFIG+=link_pulseaudio is not sufficient to get it to link, at least I'm not seeing any new libpulse dependencies in the generated rpms, https://koji.fedoraproject.org/koji/taskinfo?taskID=36960346 This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'. This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31. Regardless, build succeeded, so FTBFS issue is resolved (closing) |