[no subject]

This permits applications built on later minor release editions of the library
to be run (correctly) with earlier editions of the library, when their interface
requirements are constrained to an earlier release level. And second, it ensures
that applications which record a dependency on a given named set (minor revision
level) will not be run11 with an edition of the library which does not possess
that named set. '

> I think what James is suggesting is something similar - to,
> e.g., give all symbols introduced in GTK+-2.2 a new symbol
> version so that it's easy to tell whether an app linking
> to libgtk-2.0.so.0 (the soname for GTK+-2.2 as well as GTK+-2.0)
> requires GTK+-2.2 or just GTK+-2.0.

If the developer is careful it's even possible that a developer with Gnome 2.2
can easyly target Gnome 2.0 too, just by avoiding 2.2er functions. So users are
not all the time forced to upgrade for small utilities.

> It would be neat, but also a fair bit of work and a portability
> snag. 
It could be disabled for all platform that don't support it.

> And it doesn't catch cases where the API is implicitely extended
> -- e.g., a combination of arguments that was an error in GTK+-2.0
> works in GTK+-2.2. 
This is true.

> I think the concept of the "minor" version is probably more workable
> in practice. Something linked against libgtk-2.0.so.0.x.y
> requires a libgtk-2.0.so.0.x'.y' where x' >= x.

> ELF versioning schemes typically have minor version numbers
> but don't do anything with them.
I think that is not true, the minor versions are labeled inside the dynamic
objects. To cite again:
'So, instead of simply renaming the library (e.g. from libfoo.so.1.2 to
libfoo.so.1.3 ), the library's name remains libfoo.so.1 (reflecting its major
release level) and inside the library, a label is introduced (say, "VERS_1.3")
that indicated the GLOBAL symbols added in the third minor revision level. If
such labels are added with each minor revision level (e.g. VERS_1.1, VERS_1.2,
VERS_1.3, ...) and all earlier labels preserved within subsequent minor release
editions of the library, the evolution of the library's interface can be seen

> Libtool's versioning scheme
> will set the minor numbers appropriately when the system
> supports them.
> Regards,
>                                         Owen

So that all i know aboiut this in theory. Maybe someone from SUN who has real
experience with this should speak up and tell a bit about it. They should have
some experience: 'All of the system libraries in Solaris which provide the basic
OS and core networking services, as well as many of the basic window system
interfaces, have been versioned in this way since Solaris 2.6. The eventual goal
is to version all libraries shipped by Sun which can be used with Solaris .'

	Martin H.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]