[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Hello!! (I am still alive...)
This is how I think it works or should work... but I am no expert,
so....
The problem I see is that an ABI incompatibility could occur even
outside of the library domain... because of other libraries or whatever,
maybe a small ABI change in Allegro itself for a needed bugfix...
Maybe: liballegro.so.4.0.0, but only changing the 3rd value to fix an
ABI compatiblity problem, though some people could confuse this with
Allegro 4.0.0 where it maybe is Allegro 4.0.7 in reality (but it is
still binary compatible with liballegro 4.0.0).
Or maybe: liballegro.so.4.00, so a small ABI fix could be
liballegro.so.4.01 and when Allegro 4.2 is there, then
liballegro.so.4.20.
For the development version (WIP) just change the soname everytime,
like liballegro.so.3.9.39.
liballegro.so should point to the correct .so that it is in concordance
with the .a installed, that means that it doesn't necessary point to the
latest .so.
When you install liballegro.a, you should modify or create the symlink
liballegro.so -> liballegro.so.4.0.0 IF liballegro.a is binary
compatible with that, thats for consistency.
On packages, like for example on Debian, the liballegro.so symlink
comes in the -dev package together with liballegro.a and the header
files, to have consistency.
Well, thats what I think but I am not sure if it is correct...
Goodbye!
Peter Wang wrote:
>
> On 16 Oct 2001, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> >
> > should it not look a little more like:
> >
> > liballegro.so.3.9.39
> > liballegro.so.4.0.0
> > liballegro.so.4.0.1
> > etc...
> >
> > where:
> > liballegro.so -> link to newest major ver (liballegro.so.3/4)
> > liballegro.so.3 -> link to newest release in the 3.*
> > liballegro.so.4 -> link to newest stable release in the 4.*
>
> That's a little misleading since "3.*" only means 3.9.40+. The reason
> I chose the system I proposed is that we are (I hope) going to use
> Linux-style versioning, and that 4.2.x would most likely not be binary
> compatible with 4.0.x.
>
> The top part is the same as what I was thinking. So, more explicitly:
>
> liballegro.so -> newest version (liballegro.so.39/40/41/42)
> liballegro.so.39 -> liballegro.so.3.9.40 (and above, if any)
> liballegro.so.40 -> newest in 4.0 series (liballegro.so.4.0.x)
> liballegro.so.42 -> newest in 4.2 series (liballegro.so.4.2.x)
> etc.
--
Ivan Baldo:
lubaldo@xxxxxxxxxx - http://go.to/ibaldo - ICQ 10215364
Phone: (598) (2) 613 3223.
Caldas 1781, 11400 Malvin, Montevideo, Uruguay, South America.
(If you have problems with the previous addresses, try this ones:
ibaldo@xxxxxxxxxx, http://members.xoom.com/baldo.1).