RE: [gtk-list] Re: 1.1 <=> 1.2 not compatible, why not 2.0?
- From: "Rostedt, Steven" <steven rostedt lmco com>
- To: "'marc bowtie nl'" <marc bowtie nl>
- Cc: "'GTK-List'" <gtk-list redhat com>
- Subject: RE: [gtk-list] Re: 1.1 <=> 1.2 not compatible, why not 2.0?
- Date: Thu, 25 Mar 1999 12:29:39 -0500
> This is not correct, minor version numbers change when the library
> remains binary compatible, major version change when the binary
> compatibility gets broken.
> That allows the dynamic linker to determine whether an application
> linked against a library with a lesser minor number can still be
> used with a library with a bigger minor number, the linker then
> also knows not to use a library with a different *major* number.
You are right. My mistake. I was fooled by the way that
it's libgtk-1.2.so not libgtk.so.1.2.
It's been a while since I worked with building multiple libraries.
But it does make sense to follow this format, as you said
for marketing reasons. Actually, it should be libgtk.so.2
but I think they did this to make it easier to map to
the gtk+-1.2 version.
If you look at XFree86 they have two different numbers used.
Version 6 is the libX11.so.6 and there marketing version
3.3.3. I wonder if version 4.0 will have libX11.so.7 ?
because I don't think it is binary compatible.
This is what I meant as being standard. I was off on thinking
that the ld is the same as the versioning. My apologies :(
> The version numbers you talk about are marketing numbers.
> The scheme that gtk uses is absolutely not standard, although I must
> say that if they would have used the major.minor scheme, they would
> be at version 30.1 by now. Although they also might have chosen to
> not bother about the version number in the library in the development
> And as a final remark, the Linux version numbering scheme has nothing
> to do with shared library versioning! Except that the gtk people
> wanted to try using this scheme to indicate the development line.
Thank you for the correction.
] [Thread Prev