NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: OpenGL - browser and WebGL support - failed libGL.so
Hi Patrick,
On 2021-08-23 15:04:59 +0200 Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
> On Mon, Aug 23, 2021 at 02:46:39PM +0200, Riccardo Mottola wrote:
>> GLXtest process failed (exited with status 1): Unable to load
>> libGL.so.1
>
> This reminds me of e.g., libepoxy hardcoding "libGL.so.1", when
>
> $ ls /usr/X11R7/lib/libGL.*
> /usr/X11R7/lib/libGL.a /usr/X11R7/lib/libGL.so.3
> /usr/X11R7/lib/libGL.so /usr/X11R7/lib/libGL.so.3.0
>
> (Why hardcode the major number?)
I don't know, but you gave me a hint and grepping found this:
// see e.g. bug 608526: it is intrinsically interesting to know whether we have dynamically linked to libGL.so.1
// because at least the NVIDIA implementation requires an executable stack, which causes mprotect calls,
// which trigger glibc bug http://sourceware.org/bugzilla/show_bug.cgi?id=12225
#ifdef __OpenBSD__
libGLfilename = "libGL.so";
#else
libGLfilename = "libGL.so.1";
#endif
mOGLLibrary = PR_LoadLibrary(libGLfilename);
if (!mOGLLibrary) {
NS_WARNING("Couldn't load OpenGL shared library.");
return false;
}
at least, this is ArcticFox. I will try making NetBSD as OpenBSD and see what happens.
I wonder if SeaMonkey, also based on older Gecko code but a little bit newer, has a similar issue.
I will also check current FireFox code to see what they did/changed there and see.
Thanks,
Riccardo
--
Sent with GNUMail from iMac PowerPC 64bit running GNUstep on Debian/PPC
Home |
Main Index |
Thread Index |
Old Index