[marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
Hi, I'm working on the Mesa project's build system using autoconf, automake, and libtool. We're running into the following problem: We use the formula version-info = Major+minor:Mesa_version:Minor to compute proper libtool version-info from the OpenGL version number (1.2) and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version is an integer derived from that release number. We'd like to use Mesa_version = MM * 10^4 + Mm * 10^2 + Mt which would yield something like 30500. However libtool only accepts three digits for the REVISION part of the version-info (as Marcelo mentions below). Is it possible to extend that limitation to five or six digits? That would be greatly appreciated. Thanks in advance, Sven PS: Libtool rocks! - Forwarded message from "Marcelo E. Magallon" <[EMAIL PROTECTED]> - From: "Marcelo E. Magallon" <[EMAIL PROTECTED]> To: Brian Paul <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [Mesa3d-dev] Re: libtool (was CVS and SSE) Date: Mon, 21 May 2001 23:41:40 +0200 >> Brian Paul <[EMAIL PROTECTED]> writes: > I'm curious why revision 30500 doesn't work. Do you know if the revision > is stored as a number or a string? I'd at least ask the libtool people why > 30500 doesn't work. because libtool defines non negative as: 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9] i.e., it not only can't start with 0, it can only have three digits. I suspect this has to do with some funny test or expr implementation. Or perhaps they thought three digits would be enough. Or maybe some sick linker uses integers to store this info. Hmm... funky that '0 | [1-9]' bit... -- Marcelo ___ Mesa3d-dev mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/mesa3d-dev - End forwarded message - -- "Would the All-Seeing Eye please look in my direction?" [ KeyID: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
Sven M. Hallberg writes: > We use the formula > version-info = Major+minor:Mesa_version:Minor > to compute proper libtool version-info from the OpenGL version number (1.2) > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version > is an integer derived from that release number. We'd like to use > Mesa_version = MM * 10^4 + Mm * 10^2 + Mt > which would yield something like 30500. However libtool only accepts three > digits for the REVISION part of the version-info (as Marcelo mentions below). You must have missed the part of the documentation that says: :*_Never_* try to set the interface numbers so that they correspond : to the release number of your package. This is an abuse that only : fosters misunderstanding of the purpose of library versions. (not my emphasis) The documentation describes in detail how you are supposed to set the three version fields. Anything else will be trouble. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 failure on Solaris 8
Building ethereal: Making all in gryphon /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c packet-gryphon.c ../../libtool: test: argument expected *** Error code 1 make: Fatal error: Command failed for target `packet-gryphon.lo' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18/plugins/gryphon *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18 *** Error code 1 make: Fatal error: Command failed for target `all-recursive-am' $ ./libtool --version ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) Changing the invocation to use "-x", it ends with: + test -z gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c + test yes = yes removelist=packet-gryphon.o packet-gryphon.lo + rm -f packet-gryphon.o packet-gryphon.lo + trap rm -f packet-gryphon.o packet-gryphon.lo; exit 1 1 2 15 + test = no ../../libtool: test: argument expected *** Error code 1 make: Fatal error: Command failed for target `packet-gryphon.lo' Here's the code that breaks. It seems "pic_mode" is empty. I added the `X' prefix to the test values to make it work. $run $rm $removelist trap "$run $rm $removelist; exit 1" 1 2 15 # On Cygwin there's no "real" PIC flag so we must build both object types case $host_os in cygwin* | mingw* | pw32* | os2*) pic_mode=default ;; esac if test X$pic_mode = Xno && test "$deplibs_check_method" != pass_all; then # non-PIC code in shared libraries is not supported pic_mode=default fi So, now it gets further and breaks elsewhere :-( Ick, ick, ick. finalize_rpath= /usr/local/lib + test != yes ../../libtool: test: argument expected *** Error code 1 make: Fatal error: Command failed for target `gryphon.la' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18/plugins/gryphon *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /u/bkorb/tools/tcpdump/ethereal-0.8.18 *** Error code 1 make: Fatal error: Command failed for target `all-recursive-am' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
This patch got me through the ugly ethereal build. I applied them to "libtool", so obviously they need to be applied to the ltmain.in file. I do not know if every one of these is strictly required, I started getting impatient. :-) Regards, Bruce $ gdiff -u libtool /tmp/LIBTOOL --- libtool Thu Jun 7 10:59:32 2001 +++ /tmp/LIBTOOLThu Jun 7 10:57:07 2001 @@ -720,7 +720,7 @@ pic_mode=default ;; esac -if test $pic_mode = no && test "$deplibs_check_method" != pass_all; then +if test X$pic_mode = Xno && test "$deplibs_check_method" != pass_all; then # non-PIC code in shared libraries is not supported pic_mode=default fi @@ -739,7 +739,7 @@ # Lock this critical section if it is needed # We use this script file to make the link, it avoids creating a new file -if test "$need_locks" = yes; then +if test X"$need_locks" = Xyes; then until $run ln "$0" "$lockfile" 2>/dev/null; do $show "Waiting for $lockfile to be removed" sleep 2 @@ -2631,7 +2631,7 @@ *) finalize_rpath="$finalize_rpath $libdir" ;; esac done - if test $hardcode_into_libs != yes || test $build_old_libs = yes; then + if test X$hardcode_into_libs != Xyes || test $build_old_libs = yes; then dependency_libs="$temp_xrpath $dependency_libs" fi fi @@ -2656,7 +2656,7 @@ esac done - if test "$build_libtool_libs" = yes; then + if test X"$build_libtool_libs" = Xyes; then if test -n "$rpath"; then case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-beos*) @@ -2671,7 +2671,7 @@ ;; *) # Add libc to deplibs on all other systems if necessary. - if test $build_libtool_need_lc = "yes"; then + if test X$build_libtool_need_lc = "Xyes"; then deplibs="$deplibs -lc" fi ;; @@ -2943,8 +2943,8 @@ dlname= # Test again, we may have decided not to build it any more - if test "$build_libtool_libs" = yes; then - if test $hardcode_into_libs = yes; then + if test "X$build_libtool_libs" = Xyes; then + if test X$hardcode_into_libs = Xyes; then # Hardcode the library paths hardcode_libdirs= dep_rpath= ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: > Building ethereal: > > Making all in gryphon > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. > -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan > -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. > -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include > -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c > packet-gryphon.c > ../../libtool: test: argument expected How did you configure Ethereal 0.8.18? We built with --enable-shared --enable-static and it worked fine (we have a customized version of libtool 1.4 but out changes don't affect Solaris). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: > I'm not going to put a lot of effort into explaining this but here's > the story. > > Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. > The "1.2" indicates the library implements the OpenGL 1.2 API. > Anything else there would be VERY confusing for end users at this > point. > > The last part "xxyyzz" is usually something like 030402 to indicate > Mesa version 3.4.2. With this convention, people can look at their > libGL.so.1.2.xxyyzz file and determine which version of Mesa they're > using. It also allows various versions of libGL.so.1.2.* to coexist. > This very useful for the developers so we may easily switch between > versions when doing regression testing. So the 1.2 is "static"? Have you looked at -release? I don't know what this will do to the SONAME though. It won't give you the name above but close enough (libGL-1.2.xxyyzz.so). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
[EMAIL PROTECTED] wrote: > > On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: > > Building ethereal: > > > > Making all in gryphon > > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. > > -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan > > -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. > > -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include > > -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c > > packet-gryphon.c > > ../../libtool: test: argument expected > > How did you configure Ethereal 0.8.18? We built with --enable-shared > --enable-static and it worked fine (we have a customized version of > libtool 1.4 but out changes don't affect Solaris). as in: ./configure I couldn't use downloadable packages (like yours) because /usr/local is for global admins, so I have to configure for /u/local. [Cannot copy the files, either, because they contain compiled in path names.] I presume you saw my later patch? That failed, too, because some library was not findable. I gave up and am at home now. Thanks for your suggestion, tho. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
>> [EMAIL PROTECTED] writes: > So the 1.2 is "static"? Have you looked at -release? I don't know what > this will do to the SONAME though. It won't give you the name above > but close enough (libGL-1.2.xxyyzz.so). This is the problem. In this case the soname *must* be libGL.so.1 (on Linux). The problem is that the library is provided by several vendors, and a sane development environment is needed: if I compile foo with a particular vendor's version it must run with all the others. The exposed interface is well defined and this level of compatibility is achievable. Mesa is unique in that it's available for a multitude of platforms. Linux is the only one where this issue is critical (it'd be nice if Mesa used the native libgl's soname on every platfrom, but it's just a minor issue) What Mesa needs from libtool is libtool's knowledge about multiple platform's oddities regarding compilation and linking, but it also needs a way to be able to set the soname. Yes, this is bad in general. It defeats the whole purpose of libtool, but the problem is that Mesa is providing another version of an existing library. I can imagine things like Motif (lesstif), OpenInventor (Coin, mostly non issue now) are in the same situation. -- Marcelo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
Peter Eisentraut wrote: > > Sven M. Hallberg writes: > > > We use the formula > > version-info = Major+minor:Mesa_version:Minor > > to compute proper libtool version-info from the OpenGL version number (1.2) > > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version > > is an integer derived from that release number. We'd like to use > > Mesa_version = MM * 10^4 + Mm * 10^2 + Mt > > which would yield something like 30500. However libtool only accepts three > > digits for the REVISION part of the version-info (as Marcelo mentions below). > > You must have missed the part of the documentation that says: > > :*_Never_* try to set the interface numbers so that they correspond > : to the release number of your package. This is an abuse that only > : fosters misunderstanding of the purpose of library versions. > > (not my emphasis) > > The documentation describes in detail how you are supposed to set the > three version fields. Anything else will be trouble. I'm not going to put a lot of effort into explaining this but here's the story. Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. The "1.2" indicates the library implements the OpenGL 1.2 API. Anything else there would be VERY confusing for end users at this point. The last part "xxyyzz" is usually something like 030402 to indicate Mesa version 3.4.2. With this convention, people can look at their libGL.so.1.2.xxyyzz file and determine which version of Mesa they're using. It also allows various versions of libGL.so.1.2.* to coexist. This very useful for the developers so we may easily switch between versions when doing regression testing. I understand that libtool has a specific versioning convention and we don't want you to change that. It's just that if the REVISION part could accomodate a 6-digit number (with leading zeros) we'd be grateful. -Brian ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: : I'm not going to put a lot of effort into explaining this but here's : the story. : : Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. : The "1.2" indicates the library implements the OpenGL 1.2 API. : Anything else there would be VERY confusing for end users at this : point. You probably won't be able to use that scheme with libtool without changing libtool. libtool doesn't just pass the integers through the system for library naming reasons. Another thing is that how the numbers are set up depends on the system (e.g. on IRIX, the age part is dropped from the library filename, and the current part is incremented by one). Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
