Fix gstreamer runtime loading on OpenBSD

RESOLVED FIXED in mozilla27

Status

()

Core
Audio/Video
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: gaston, Assigned: gaston)

Tracking

unspecified
mozilla27
x86
OpenBSD
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
After bug 859199, gstreamer is loaded at run-time via dlopen, but this fails on OpenBSD due to the specificities of our platform : we dont have the symlink forest other unix OSes do (ie libfoo.so, libfoo.so.X, and libfoo.so.X.Y), we only have libfoo.so.X.Y and if dlopen() is given libfoo.so, it will open automagically the correct lib.

This has already been debated at length whether it should be fixed in NSPR in bug #650772 but the gstreamer loader doest use nspr, and a precedent was fixed the same way in #667325. Youtube itself stalls if i have media.gstreamer.enabled, manually do the three gstreamer symlinks on my system and try to load an h264 stream, and if i dont have the symlinks it fallbacks to webm and an internal decoder. So the gst backend itself might have an issue, but we should at least fix the loading of the needed libs.
(Assignee)

Updated

4 years ago
Depends on: 859199
(Assignee)

Comment 1

4 years ago
Created attachment 818493 [details] [diff] [review]
Proposed fix: dlopen the unversioned lib on OpenBSD

Proposed fix, testing needed locally but you get the idea..
Assignee: nobody → landry
Attachment #818493 - Flags: review?(edwin)

Comment 2

4 years ago
Comment on attachment 818493 [details] [diff] [review]
Proposed fix: dlopen the unversioned lib on OpenBSD

Stealing from Edwin while he's on a break, thanks for the patch!
Attachment #818493 - Flags: review?(edwin) → review+
https://hg.mozilla.org/mozilla-central/rev/d50df2233e95
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.