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

proper value for --version-info



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
pelliott@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

Attachment: signature.asc
Description: Digital signature


Reply to: