Hi Patrick,
On 2021-08-23 15:04:59 +0200 Patrick Welche <pr...@cam.ac.uk> 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
