On 23/08/2025 00:40, Joseph Maloney wrote:
For this example I built GNUstep on debian from sources using
tools-script. I then just built terminal from gap.
jmaloney@debian:~/gap/system-apps/Terminal$ ldd Terminal.app/Terminal
linux-vdso.so.1 (0x00007fc0cad1f000)
libgnustep-gui.so.0 =>
/usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0
(0x00007fc0ca600000)
libgnustep-base.so.1.31 =>
/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.31
(0x00007fc0c9e00000)
libobjc.so.4.6 =>
/usr/GNUstep/System/Library/Libraries/libobjc.so.4.6 (0x00007fc0cac89000)
For base why does it link to a specific version?
/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.31
Instead of:
/usr/GNUstep/System/Library/Libraries/libgnustep-base.so.0
Is there a build option to make base work the same way as gui so I can
upgrade core libs without affecting applications?
Joseph Maloney
A version number has three components: major, minor, and subminor.
In the above example libgnustep-gui.so.0 matches anything with the major
version number zero, while libgnustep-base.so.1.31 metches anything with
major version number 1 and minor version number 31
None of the examples above are actually using a 'specific' version, but
none is completely unversioned.
Conventionally in GNUstep,
the major version number is changed for political/marketing reasons
(development reasches some important target etc).
the minor version number is changed for software compatibility reasons
(where existing code using the library might be broken)
the subminor number is changed for bugfixes (should not break any
existing code).
So for your purposes, (being able to upgrade the library without
changing existing apps), the current linkage is correct for base, but
too lax for gui (you could upgrade to a gui version which would break
the existing apps).
Normally the interface for a library package is set in
packagename_INTERFACE_VERSION, but looking at the git repository I see
that was removed from the GUI makefile around release 0.30
