[Top][All Lists]

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

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

From: Nicolas Mendoza
Subject: RE: [png-mng-implement] -version-number and BeOS
Date: Wed, 10 May 2006 23:02:52 +0200
User-agent: Opera Mail/9.00 (Linux)

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

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

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).

I've seem to have run into a similar problem, what _is_ really the problem?

/bin/sh ../libtool --tag=CC --mode=link ppc-amigaos-gcc -g -O2 -Wall -W -o -rpath /usr/local/amiga/lib -no-undefined -version-number 3:8:2 tif_aux.lo tif_close.lo tif_codec.lo tif_color.lo tif_compress.lo tif_dir.lo tif_dirinfo.lo tif_dirread.lo tif_dirwrite.lo tif_dumpmode.lo tif_error.lo tif_extension.lo tif_fax3.lo tif_fax3sm.lo tif_flush.lo tif_getimage.lo tif_jpeg.lo tif_luv.lo tif_lzw.lo tif_next.lo tif_ojpeg.lo tif_open.lo tif_packbits.lo tif_pixarlog.lo tif_predict.lo tif_print.lo tif_read.lo tif_strip.lo tif_swab.lo tif_thunder.lo tif_tile.lo tif_unix.lo tif_version.lo tif_warning.lo tif_write.lo tif_zip.lo ../port/ -ljpeg -lz -lm -lc
libtool: link: CURRENT `' must be a nonnegative integer
libtool: link: `3:8:2' is not valid version information

Nicolas Mendoza

reply via email to

[Prev in Thread] Current Thread [Next in Thread]