Closed Bug 687320 Opened 9 years ago Closed 9 years ago
Try to open correct lib
GL .so on Open BSD
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)
Better patch that applies against tip.
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.
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
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
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.