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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Avoiding to install some static libs
On 16-mei-2006, at 16:06, Pierre Ossman wrote: Hi! I'd like to avoid installing some of the static libs built, but I can't figure out how. I have a package that contains both "normal" libraries, for which I'd like both dynamic and static to be installed, and some modules. I'd like to kill off the static versions of the modules as they serve no purpose. If I understand you correctly then what you want is the -shared option that is available in the CVS version of libtool. See also: http://lists.gnu.org/archive/html/libtool/2003-08/ msg8.html I have been struggling with the same problem and am eagerly waiting for this option to become available in a public version of libtool. I am currently using a not so elegant post-install workaround to get rid of the .a files: install-exec-hook: rm -f $(DESTDIR)$(yourmoduledir)/yourmodule.a I tried adding --tag=disable-static when doing libtool -- mode=install, but that didn't help. Any other ideas? I'd like to keep building the libs, as they might be used for preloading. But if there is a way to disable building them (figuring out how to get automake to give libtool the --tag probably) but not a way to disable installing them, then that is possible solution, although not preferable. -- Rgds Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
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]> ___ http://lists.gnu.org/mailman/listinfo/libtool
autoreconf --help (was: Libtool release plan)
Hi Olly, * Olly Betts wrote on Tue, May 16, 2006 at 01:38:05PM CEST: > > I'm guessing the issue is that the tarball builder reuses the same > SVN checkout and just reruns "autoreconf" without "--force". The > output from "autoreconf --help" says: > > Run `autoconf' (and `autoheader', `aclocal', `automake', `autopoint' > (formerly `gettextize'), and `libtoolize' where appropriate) > repeatedly to remake the GNU Build System files in the DIRECTORIES or > the directory trees driven by CONFIGURE-AC (defaulting to `.'). > > By default, it only remakes those files that are older than their > predecessors. If you install new versions of the GNU Build System, > running `autoreconf' remakes all of the files by giving it the > `--force' option. > > I had read that as saying "if you upgrade autoconf, automake, or libtool > then running autoreconf implicitly uses the `--force' option", but > rereading it I think it probably isn't saying that. > > And the info manual makes this totally clear: *snip* > I suggest that autoreconf's --help should follow the info version - > in particular "sources" is better than "predecessors" and the > last sentence is a lot clearer in the info version. Yes, that is a good idea IMHO. At the same time let's get rid of the CONFIGURE-AC argument we're suggesting there but which didn't work right anyway. But let's not actually change the functionality, so that what works continues to. (A bit fragile, I know; I think the long term goal should be to implement that functionality properly, in all autotools; but I don't want to do that now.) OK to apply? Do you think we need to announce this change in NEWS? Cheers, Ralf * bin/autoreconf.in ($help): Reword according to the manual. Suggested by Olly Betts. Index: bin/autoreconf.in === RCS file: /cvsroot/autoconf/autoconf/bin/autoreconf.in,v retrieving revision 1.132 diff -u -r1.132 autoreconf.in --- bin/autoreconf.in 17 May 2006 02:20:15 - 1.132 +++ bin/autoreconf.in 17 May 2006 17:11:21 - @@ -55,16 +55,16 @@ # $HELP # - -$help = "Usage: $0 [OPTION] ... [CONFIGURE-AC or DIRECTORY] ... +$help = "Usage: $0 [OPTION] ... [DIRECTORY] ... Run `autoconf' (and `autoheader', `aclocal', `automake', `autopoint' (formerly `gettextize'), and `libtoolize' where appropriate) -repeatedly to remake the GNU Build System files in the DIRECTORIES or -the directory trees driven by CONFIGURE-AC (defaulting to `.'). +repeatedly to remake the GNU Build System files in specified +DIRECTORIES and their subdirectories (defaulting to `.'). By default, it only remakes those files that are older than their -predecessors. If you install new versions of the GNU Build System, -running `autoreconf' remakes all of the files by giving it the +sources. If you install new versions of the GNU Build System, +you can make `autoreconf' remake all of the files by giving it the `--force' option. Operation modes: ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf --help (was: Libtool release plan)
On Wed, May 17, 2006 at 07:19:57PM +0200, Ralf Wildenhues wrote:
> At the same time let's get rid of the
> CONFIGURE-AC argument we're suggesting there but which didn't work right
> anyway. But let's not actually change the functionality, so that what
> works continues to. (A bit fragile, I know; I think the long term goal
> should be to implement that functionality properly, in all autotools;
> but I don't want to do that now.)
Another approach would be to change autoreconf to just remove any
filename part - that's easy to explain to the user ("the top-level
directory or any file in it") and also easy to implement (simply
s,[^/\\]*$,, on that argument.)
Cheers,
Olly
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf --help
Hi Olly,
* Olly Betts wrote on Wed, May 17, 2006 at 08:56:28PM CEST:
> On Wed, May 17, 2006 at 07:19:57PM +0200, Ralf Wildenhues wrote:
> > At the same time let's get rid of the
> > CONFIGURE-AC argument we're suggesting there but which didn't work right
> > anyway. But let's not actually change the functionality, so that what
> > works continues to. (A bit fragile, I know; I think the long term goal
> > should be to implement that functionality properly, in all autotools;
> > but I don't want to do that now.)
>
> Another approach would be to change autoreconf to just remove any
> filename part - that's easy to explain to the user ("the top-level
> directory or any file in it") and also easy to implement (simply
> s,[^/\\]*$,, on that argument.)
Well, the point is that
autoreconf subdir/foobar.ac
simply won't cause the called tools to use foobar.ac, but the first that
exists in the list
subdir/configure.ac
subdir/configure.in
The file name you pass currently is stripped off as you suggest, but
since it won't be used, I think that it is confusing to document this
unless it is actually used.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf --help
On 2006-05-17, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Well, the point is that > autoreconf subdir/foobar.ac > > simply won't cause the called tools to use foobar.ac, but the first that > exists in the list > subdir/configure.ac > subdir/configure.in Yeah, I know. My thought was that it is sometimes convenient to be able to do something like: for f in `find . -name configure.ac -print` ; do autoreconf $f ; done But it's not a big deal - it's not hard for the user to chop the leaf themselves in the case above, and as you say it's a bit odd to accept a filename to indicate just a directory. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf --help
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > OK to apply? Yes, and thanks. > Do you think we need to announce this change in NEWS? Not really. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf --help
Hi Paul, * Paul Eggert wrote on Thu, May 18, 2006 at 08:45:37AM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > OK to apply? > > Yes, and thanks. Done, thanks! Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
