-version-number and BeOS

Hi John,

* John Bowler wrote on Wed, May 17, 2006 at 04:17:21AM CEST:
> From: Ralf Wildenhues
> >What I still don't understand is the following
additional change you
> >also suggest:
> >
> >> $ diff libpng-1.2.9beta7/ltmain.sh
libpng-1.2.9beta11 3248c3248
> >> <           current=`expr $number_major +
$number_minor - 1`
> >> ---
> >> >           current=`expr $number_major +
$number_minor`
> >> 3323c3323
> >> <         major=`expr $current - $age + 1`
> >> ---
> >> >         major=`expr $current - $age`
> >
> >There is a comment above this code that explains
why this should be
>> necessary, no?
> 
> This is the irix/nonstopux case, I don't think there
is any comment; I
> wasn't able to find any explanation of why the irix
case adds 1 to get
> the major version number.  I did notice the comment for
the first case
> which says:
> 
> 'then there is irix which has an extra 1 added just
for fun'

AFAIK IRIX doesn't or at one point in time didn't allow
for a major
version number of 0.  That's why Libtool always added 1:
because version
numbers of 0 are commonly used elsewhere, so it wouldn't be
nice to
force everyone else to adjust.

> That's clearly a reference to the second case adding
of 1, not a
> reference to whatever irix behaviour the second piece
of code is trying
> to accommodate.
> 
> The issue here is that libpng on irix has (currently) a
major version
> number of '0', as it does on all other operating
systems.

Why should the version number be constant across operating
systems?
This is a requirement that is impossible to fulfill
portably.
I fully understand that the maintenance hassles incurred by
this
limitations: explaining to users that their libfoo 1.2.3 has
different
numbers 4.5.6 elsewhere; but fundamentally, it simply isn't
possible to
generate a uniform numbering scheme.

> So we need to be able to set the major version number
to 0 (currently
> impossible because ltmain.sh objects to the value of
'-1' for current)
> and, ideally we don't want to do OS specific stuff in
configure to fix
> up the arguments to libtool for irix...  That would
defeat the point
> of libtool.

Well, the point of libtool is that you give it the same
version
information for all systems, and that it will map that to
some version
representation that keeps the semantics w.r.t. compatible
and
incompatible changes right.  A library on IRIX need not be
compatible
with a library on GNU/Linux: they will never be linked
together.

> Well, there is obviously something weird going on on
IRIX.  libpng has
> worked on IRIX for a long time, but maybe not with
shared libraries.
> Still it seems weird that libtool should make a major
version number
> of 0 impossible and not offer any explanation of what
is going on.

Good point.  We should document this somewhere, after
clarifying where
exactly the constraint came from and whether it still
applies.

Cheers,
Ralf


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement

From: Ralf Wildenhues [mailto:Ralf.Wildenhuesgmx.de] 
>John Bowler:
>> The issue here is that libpng on irix has
(currently) a major version

>> number of '0', as it does on all other operating
systems.
>
>Why should the version number be constant across
operating systems?

It isn't.  The *major* version number is the same across
all operating
systems (all the ones libpng supports.)  In so far as this
issue is
concerned I believe libpng is supported on a sufficient
variety of
platforms to exercise all the different cases in ltmain.sh -
so I think
we are testing all the different varieties of version number
mangling
in libtool.

libpng has an existing (one-makefile-per-os) build system
which produces
shared libraries for each operating system with a particular
version
number.  Across minor revisions (including API adds) the
major number
does not change and must not change (on any platform). 
Across a major
revision the library and include file *names* change, and we
keep the
same major version number.

When we tried to get a configure script to work in 1.2.9 (a
minor
revision from package version 1.2.8) we obviously wanted the
configure
stuff to generate the same shared library names+*major*
versions as the
makefiles.  Indeed this is a requirement - we need to
continue to
support libpng12 without a major shared library revision. 
Since we
wanted to swap to a configure script build by default we had
to have
it generate the required major versions across all
platforms.

When I tried to do this with --version-info I discovered
that I couldn't
get the correct result (even with a change to major version
number) on
freebsd.  IIRC to set the minor part of the version number
on *linux*
I had to supply a non-zero 'age' but if I did that it
would change the
*major* version on freebsd.  This is discussed at length in
the
png-implement archives.  The conclusion was that the
required value for
--version-info had to be changed for different Oses.

When I tried this with --version-number, however, I found it
was
portable;
I could set a single version number for all Oses.  libtool
correctly
removes the spurious parts - so the version number is 0:9:0
and we get
libpng12.so.0.9.0 on linux and libpng12.so.0 on freebsd.

Notice that we *did* change our version numbering scheme to
get this to
work - but only in the minor part (we had
libpng12.so.0.1.2.8 before on
linux).

Of course we then found that the irix build fails.

This is all documented on the png-implement archive.  The
important
points
are:

1) We want to use minor versioning on the platforms which
support it.
2) The major version must not change on any platform between
successive
   (minor revision) configure builds.
3) We could change the major version to be (say) '1' at
the next major
   release, but we can't change it in libpng 1.2.x

John Bowler <jbowleracm.org>



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement