Try to open correct libGL.so on OpenBSD

RESOLVED FIXED in mozilla10

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: gaston, Assigned: gaston)

Tracking

Trunk
mozilla10
x86
OpenBSD
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
Followup to bug #650772, similar to #667325 and loosely related to #681026, i'm trying to test webGL on fx 7/trunk on OpenBSD, this won't work atm as we only have mesa 7.8.2 (but the update to 7.10.3 is in the works), but at least that patch makes glxtest and GLXLibrary::EnsureInitialized() try to open an existing libGL lib. On OpenBSD, libGL.so.1 doesn't exist, and the so version changes over time (see #650772 for more details), using libGL.so will ensure the last libGL.so installed is opened.

With that change (applied against 7.0b5, but patch is against trunk), at least the symbols are correctly checked (we're lacking glXBindTexImageEXT and glXReleaseTexImageEXT but i suppose that's a different issue)
(Assignee)

Comment 1

6 years ago
Created attachment 560769 [details] [diff] [review]
Open libGL.so on OpenBSD
Attachment #560769 - Flags: review?(bjacob)
(Assignee)

Comment 2

6 years ago
Created attachment 561141 [details] [diff] [review]
Open libGL.so on OpenBSD

Better patch that applies against tip.
Assignee: nobody → landry
Attachment #560769 - Attachment is obsolete: true
Attachment #560769 - Flags: review?(bjacob)
Attachment #561141 - Flags: review?(bjacob)
Comment on attachment 561141 [details] [diff] [review]
Open libGL.so on OpenBSD

Looks fine; sorry for the long review delay.
Attachment #561141 - Flags: review?(bjacob) → review+
Wait! why don't we just open libGL.so everywhere? At least here on debian, it is a symlink to libGL.so.1.

If the reason is that we don't want to crash when a new ABI-incompatible libGL.so comes out, then the present OpenBSD patch is not acceptable for this reason; but I rather think that OpenGL will never break ABI (or even API) compatibility since it never has in 15 years of existence; and when OpenGL ES 2 broke compatibility, the library name was libGLESv2.so not libGLES.so.

So I'd rather just use libGL.so everywhere.
Created attachment 566731 [details] [diff] [review]
Counter-proposal: always go for libGL.so since libGL should never break compatibility

See above comment for rationale.

Not sure whom to ask for review. Ted knows stuff and commented on the other bug.
Attachment #566731 - Flags: review?(ted.mielczarek)
Comment on attachment 566731 [details] [diff] [review]
Counter-proposal: always go for libGL.so since libGL should never break compatibility

Review of attachment 566731 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not sure that I'm the right reviewer here, but I don't have a better suggestion, and this looks pretty reasonable.
Attachment #566731 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 566731 [details] [diff] [review]
Counter-proposal: always go for libGL.so since libGL should never break compatibility

Unfortunately, on our very own fedora 12 test slaves, libGL.so does not exist.
Attachment #566731 - Attachment is obsolete: true
Pushed Landry's patch:
http://hg.mozilla.org/integration/mozilla-inbound/rev/df2b31a1e4c4

Comment 9

6 years ago
https://hg.mozilla.org/mozilla-central/rev/df2b31a1e4c4
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
(Assignee)

Comment 10

6 years ago
Thanks! I'd have gone the libGL.so route too, but i'm not surprised some oses only carry the versionned lib/soname.
You need to log in before you can comment on or make changes to this bug.