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