Re: [png-mng-implement] -version-number and BeOS
On 5/17/06, John Bowler [EMAIL PROTECTED] wrote: 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 Should we do that? We haven't, so far, in 1.4.0betaN. We could skip right to 1.4.1 now. Glenn
RE: [png-mng-implement] -version-number and BeOS
From: Glenn Randers-Pehrson On 5/17/06, John Bowler [EMAIL PROTECTED] wrote: 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 Should we do that? We haven't, so far, in 1.4.0betaN. We could skip right to 1.4.1 now. I think we should do that in 1.4.0betaN+1 - there's no reason to skip to 1.4.1. It just means that the shared library will be libpng14.so.1, rather than libpng14.so.0. The number '0' (current) or '1' (proposed) is hardwired in Makefile.am That looks like a major release, but since 1.4.0 is still in beta the preceding major - libpng14.so.0 - was never public. Notice that in 1.4.x 'x' is the *minor* release. So we have: libpng 1.2.9 -- libpng12.so.0.9.0 libpng 1.2.10 -- libpng12.so.0.10.0 libpng 1.4.0 -- libpng14.so.0.0.0 (currently) libpng 1.4.0 -- libpng14.so.1.0.0 (proposed) The 'compatibility' named library (libpng.so.3) shouldn't be generated by 1.4 (at least, I think that is what we agreed - there is absolutely no reason to generate it!) John Bowler [EMAIL PROTECTED]
Re: [png-mng-implement] -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
RE: [png-mng-implement] -version-number and BeOS
From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [png-mng-implement] -version-number and BeOS
Hello John, Christian, everyone, Sorry for the huge delay. * John Bowler wrote on Fri, Mar 31, 2006 at 09:15:42PM CEST: From: Christian Biesinger libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `0:9:0' is not valid version information make[1]: *** [libpng12.la] Error 1 The cause of this problem seems to be this: For BeOS, version_type=none. But, the code in ltmain.sh around line 3236 does not handle a value of none. Only for the specific list of cases does it assign a value to current, age and revision. Yes, we found a similar problem with irix and I patched ltmain.sh to fix this (ltmain.sh is shipped with the package, so patching it works): OK, I looked at this again. My previous analysis was plain wrong. I've installed the attached patches to branch-1-5 and HEAD, respectively. 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? For BeOS try adding 'none' to the end of the test for darwin|linux|osf|windows on line 3237 of ltmain.sh. We can ship libpng with that because it won't break anything which isn't already broken. I.e: Done. Cheers, and thank you for your persistence! Ralf HEAD: 2005-05-14 John Bowler [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_mode_link): For version_type `none', we still need to set `current', `age', and `revision', so that our checks don't barf. The values won't be used later. Apparently reported by several people, several times, for BeOS. * NEWS, THANKS: Update. branch-1-5: 2005-05-14 John Bowler [EMAIL PROTECTED] * ltmain.in (link mode): For version_type `none', we still need to set `current', `age', and `revision', so that our checks don't barf. The values won't be used later. Apparently reported by several people, several times, for BeOS. * NEWS, THANKS: Update. 2005-05-14 John Bowler [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_mode_link): For version_type `none', we still need to set `current', `age', and `revision', so that our checks don't barf. The values won't be used later. Apparently reported by several people, several times, for BeOS. * NEWS, THANKS: Update. Index: NEWS === RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.192 diff -u -r1.192 NEWS --- NEWS23 Mar 2006 22:39:41 - 1.192 +++ NEWS14 May 2006 08:17:56 - @@ -31,6 +31,8 @@ * Support for Interix 3 (Windows SFU). * Basic support for PIE (position-independent executables). * Initial support for RDOS. +* Fix error with -version-info on systems with version_type=none, such + as BeOS. * Bug fixes. New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team: Index: THANKS === RCS file: /cvsroot/libtool/libtool/THANKS,v retrieving revision 1.55 diff -u -r1.55 THANKS --- THANKS 23 Mar 2006 22:39:41 - 1.55 +++ THANKS 14 May 2006 08:17:56 - @@ -74,6 +74,7 @@ Bruno Haible [EMAIL PROTECTED] Carl D. Roth [EMAIL PROTECTED] Chris P. Ross[EMAIL PROTECTED] + Christian Biesinger [EMAIL PROTECTED] Dalibor Topic[EMAIL PROTECTED] Daniel Reed [EMAIL PROTECTED] DJ Delorie [EMAIL PROTECTED] @@ -90,6 +91,7 @@ Jeremy C. Reed [EMAIL PROTECTED] Joel N. Weber II [EMAIL PROTECTED] Joerg Sonnenberger [EMAIL PROTECTED] + John Bowler [EMAIL PROTECTED] Joseph Beckenbach III[EMAIL PROTECTED] Kenneth Albanowski [EMAIL PROTECTED] Kevin Ryde [EMAIL PROTECTED] Index: libltdl/config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.42 diff -u -r1.42 ltmain.m4sh --- libltdl/config/ltmain.m4sh 22 Apr 2006 18:57:04 - 1.42 +++ libltdl/config/ltmain.m4sh 14 May 2006 08:17:58 - @@ -4299,7 +4299,7 @@ # which has an extra 1 added just for fun # case $version_type in - darwin|linux|osf|windows) + darwin|linux|osf|windows|none) current=`expr $number_major + $number_minor` age=$number_minor revision=$number_revision 2005-05-14 John Bowler [EMAIL PROTECTED] * ltmain.in (link mode): For
