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.
Attachment:
signature.asc
Description: PGP signature