Re: [png-mng-implement] -version-number and BeOS

[Ralf Wildenhues]

* Christian Biesinger wrote on Fri, Mar 31, 2006 at 10:32:30PM CEST:
> John Bowler wrote:
> >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.  
> 
> Yep, that fixes it, thanks. Will 1.2.9 contain that fix?

Except that hack fixes a symptom, but not the underlying issue.

It would great if someone with BeOS access and experience investigate
the versioning system they use for shared libraries, and we could code
that into Libtool then, to really fix this.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [png-mng-implement] -version-number and BeOS

[Christian Biesinger]

Ralf Wildenhues wrote:

Except that hack fixes a symptom, but not the underlying issue.


It seems to me that this is a bug in any case. Not only is 
-version-number inconsistent with -version-info here. Even if BeOS has a 
versioning system for libraries and libtool gets support for that, this 
would still leave -version-number broken for other platforms where 
version_type=none (seems to be amigaos, os2 and sysv4 (in some cases)).


Or are you saying that -version-* should not be passed to libtool if the 
target doesn't have versioning support?



It would great if someone with BeOS access and experience investigate
the versioning system they use for shared libraries, and we could code
that into Libtool then, to really fix this.


That would be preferrable but still leave the other mentioned platforms 
broken.



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: [png-mng-implement] -version-number and BeOS

[John Bowler]

From: Christian Biesinger
>It seems to me that this is a bug in any case. Not only is 
>-version-number inconsistent with -version-info here. Even if BeOS has a 
>versioning system for libraries and libtool gets support for that, this 
>would still leave -version-number broken for other platforms where 
>version_type=none (seems to be amigaos, os2 and sysv4 (in some cases)).

It's like evaluating 0/0 - on an OS with no version numbering there is
no defined way to map the non-existent OS version number back to the
corresponding version info data.

The fix isn't really a hack because it simply defines that such OSes
go through the path shared by linux, macos(darwin) and windows.  The
result is later discarded by the version-info code so the actual values
are not important.  An alternative fix is to simply set all the values
to '1', but that would be a bigger change...

It would be better if we could use version-info across all the platforms,
but it is not possible to obtain consistent behaviour across the various
platforms with a single set of current:age:revision.  That's because
some platforms produce a 'major' of (current-age) and some calculate a
major of (current).  With libpng we ensure that minor package revisions
(e.g. package 1.2.8->1.2.9) change the ABI compatibly, so we need the
'major' to remain constant on all platforms across a minor package
revision.

For example compare the code for the determination of major in the
cases for freebsd-elf (major=".$current") and linux
(major=".($current - $age)".  This defines an inconsistent set of ABI
versions for any package currently running on both FreeBSD and Linux
(even though the semantic of a major version change is defined the
same on FreeBSD as Linux - indeed it is actually documented on
FreeBSD!)  A compatible ABI change, such as the add of a new
interface, increments current and age, so the major remains
unchanged (compatible ABI) on Linux but there is a new ABI on
FreeBSD.

Fortunately -version-number does what libpng requires - ensures that
the major version *only* changes on an incompatible ABI change.  Apart
from the two bugs (failure in 'none' and irix fails if the major version
number is 0) we haven't seen any problems (yet).

John Bowler <[EMAIL PROTECTED]>
 


___
http://lists.gnu.org/mailman/listinfo/libtool