The first version of libswe in debian
was 1.77.00. so the value of --version-info was 0:0:0
libswe_la_LDFLAGS =3D \
-version-info 0:0:0 \
-lm \
-export-symbols-regex ^swe_
Note only symbols beginning swe_ are exposed.
version 1.78.00 which was never released, added
a new symbol beginning swe_ but it did not change
the meaning of any of the old ones so the
--version-info for that version should be 1:0:1
I built and checked that version privately, so I
consider it a virtual release.
Version 1.79.00 does not add any new swe_ symbols at all over 1.78.
But new #define preprocessor constansts are added,
and the old functions produce new results for these constants.
In addition some of the 1.78.00 behavior was a bug. It produced
the wrong answer. This has been fixed so that the 1.79.00
gives the correct documented answer.
Under these conditions what is the proper value for
1.79.00 --version-info?
The reason for my confusion is this section of Libtool:
7.3 Updating library version information
https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
It says:
The following explanation may help to understand the above
rules a bit better: consider that there are three possible
kinds of reactions from users of your library to changes in a
shared library:
1. Programs using the previous version may use the new version as
drop-in replacement, and programs using the new version can
also work with the previous one. In other words, no
recompiling nor relinking is needed. In this case, bump
revision only, don't touch current nor age.
2. Programs using the previous version may use the new version as
drop-in replacement, but programs using the new version may
use APIs not present in the previous one. In other words, a
program linking against the new version may fail with
unresolved symbols if linking against the old version at
runtime: set revision to 0, bump current and age.
3. Programs may need to be changed, recompiled, relinked in order
to use the new version. Bump current, set revision and age to
0. In the above description, programs using the library in
question may also be replaced by other libraries using it.
I believe that 1) is not true. Because
and programs using the new version can also work with the
previous one
is not true. They will try to use the new #define in the .h files
and they will not work.
The first part of 2) is true:
Programs using the previous version may use the new version
as drop-in replacement, but programs using the new version may
use APIs not present in the previous one.
but the second part of 2) is not true:
In other words, a program linking against the new version may
fail with unresolved symbols if linking against the old
version at runtime
This is not true because the linker never sees the new interface. It
is hidden by new behavior on calls with new #define in constants.
3) is not true.
So the answer depends on weather I should count 2) as true!
What do the Debian experts think?
I always update the debian/libsweX.symbols file for a new
release. In this case it shows no new symbols.
Thank You.
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
---
Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it. Edward Snowden
signature.asc
Description: Digital signature
