Re: OpenGL - browser and WebGL support - failed libGL.so

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Mon, Aug 23, 2021 at 01:29:43PM -0400, Greg Troxel wrote:
> 
> neitzel%hackett.marshlabs.gaertner.de@localhost (Martin Neitzel) writes:
> 
> >> >     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?)
> >
> > The convention is that the major number reflects the shared lib's API,
> > while minor numbers are used for bug fixes and internal improvements.
> >
> > *IF* the GL folks have taken care to keep their API downwards-compatible,
> > you can safely
> 
> That's close but not quite.
> 
> First, this is about ABI not API.
> 
> In theory, the major number is incremented when there is an ABI break,
> meaning that something built for the older version will fail in the new
> version.  So a change in intended semantics, in layout of structures
> passed as args or returned, or a function being withdrawn are all ABI
> breaks.
> 
> Adding a new function is fine, and bugfixes, and all of these can just
> increment the minor.

I think in this case for "GL folks" read "xsrc" folks if I'm not
mistaken. It's been a while, but I think that number "3" might not
be what you think...


Cheers,

Patrick