On Mon, Aug 23, 2021 at 01:29:43PM -0400, Greg Troxel wrote: > > neit...@hackett.marshlabs.gaertner.de (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