version and release number
Hi I've just started using libtool and in the manual you read: 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. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release. what I don't understand is the "not binary compatible": if I use, say 1.0 for the release flag (and the version number correctly as stated in the manual), and release another implementation of the library with the incremented version number but with the same release number, why won't it be binary compatible? Or does "not binary compatible" apply only if I increment also the release number? Is it better to use only version number? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
Bob Friesenhahn wrote: On Thu, 16 Apr 2009, Lorenzo Bettini wrote: 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. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release. what I don't understand is the "not binary compatible": if I use, say 1.0 for the release flag (and the version number correctly as stated in the manual), and release another implementation of the library with the incremented version number but with the same release number, why won't it be binary compatible? Or does "not binary compatible" apply only if I increment also the release number? I sense some confusion. :-) well... :-) The -release option specifies part of the base naming for your library so that it becomes part of the base library name. For example, libfoo-1.0.so and libfoo-2.0.so. To the operating system these libraries are completely different and might have well been named libfoo.so and libbar.so. The libraries might otherwise be entirely the same and could be "binary compatible" but the operating system won't know it. Very few packages use the -release option. OK, so they would be different because they'd have a different name; but if I used the same release number (e.g., only the major number for example 1, instead of 1.1) they'd still be compatible, wouldn't they? I mean "not binary compatible" in the documentation refers only to different names The -version-info option specifies library versioning information that the operating system will use when deciding which similarly named library to use. On most Unix systems, this forms the numeric part in the library file name after ".so". Different systems use different rules when deciding how to treat this version information. Assuming that libraries are from the same release, the correct library will be used as long as you follow the libtool rules when updating the -version-info argument. There are many forms of "binary compatible". For example, a newer library might add a new function but otherwise be the same so an already existing application (using an older library) can safely use it. A newer application depending on the newer library could not safely use the older library since it might be using the new function the new function might not be present. so would you suggest to use only version info and no release info, am I right? I was only concerned about the fact that the release number of the library is not visible anywhere and that it would force the use to specify a name together with the number... thanks Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
Bob Friesenhahn wrote: On Thu, 16 Apr 2009, Lorenzo Bettini wrote: so would you suggest to use only version info and no release info, am I right? I was only concerned about the fact that the release number of the library is not visible anywhere and that it would force the use to specify a name together with the number... There are a few reasons for using release info. Some projects don't care about binary compatibility or updates to libraries so they could use release info to differentiate between releases. Other projects maintain parallel branches of the software (e.g. older and newer) and want an easy way to allow the multiple branches to be distributed without fear that they will collide with other branch's version info and end up producing shared libraries with the same names. OK, so probably if a library changes radically from one (major) release number to another (e.g., qt3 and qt4), it makes sense to append the major release number to the name of the library, so that the user of the library has to make explicit the library release he intends to use, right? thanks Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
printing library version
Hi if I want to print the library version from a program I cannot simply current:revision:age because that does not correspond to the actual lib file name, e.g., 2:0:1 corresponds to mylib.so.1.1.0... is it correct to print 2:0:1 or 1.1.0? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: printing library version
Ralf Wildenhues wrote: Hi Lorenzo, * Lorenzo Bettini wrote on Tue, May 19, 2009 at 11:58:04PM CEST: if I want to print the library version from a program I cannot simply current:revision:age because that does not correspond to the actual lib file name, e.g., 2:0:1 corresponds to mylib.so.1.1.0... is it correct to print 2:0:1 or 1.1.0? What do your users need the data for? If this is for purely informational purposes, then it probably doesn't even matter what you print. If you need it for a technical reason, well, I would like to understand that use case then. I just wanted to print this version information together with a program's version information just to show which version of a library the program is using... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: printing library version
Jason Curl wrote: But I agree with Tor here, the "Library Version" doesn't necessarily have to be the "Library API version" which is how I understand libtool. yes, actually I mean library API version... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
building a completely static executable (using boost regex library)
Hi I was trying to build, in linux, a completely static executable that uses libboost_regex; I issued configure LDFLAGS="-static" make LDFLAGS="-all-static" but when it comes to linking I get this error: /bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -L/usr/lib -all-static -o check-regexp check-regexp_cmd.o check-regexp.o -lboost_regex ../gl/libgnu.la libtool: link: g++ -g -O2 -static -o check-regexp check-regexp_cmd.o check-regexp.o -L/usr/lib -lboost_regex ../gl/.libs/libgnu.a /usr/lib/libboost_regex.a(static_mutex.o): In function `boost::scoped_static_mutex_lock::unlock()': (.text+0x16): undefined reference to `pthread_mutex_unlock' [...] /usr/lib/gcc/i486-linux-gnu/4.3.3/libstdc++.a(locale.o): In function `__gnu_cxx::__scoped_lock::~__scoped_lock()': (.text._ZN9__gnu_cxx13__scoped_lockD1Ev[__gnu_cxx::__scoped_lock::~__scoped_lock()]+0x18): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/i486-linux-gnu/4.3.3/libstdc++.a(locale.o): In function `std::locale::_Impl::_M_install_cache(std::locale::facet const*, unsigned int)': (.text._ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEj+0x2a): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/i486-linux-gnu/4.3.3/libstdc++.a(locale.o): In function `std::locale::_Impl::_M_install_cache(std::locale::facet const*, unsigned int)': (.text._ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEj+0x56): undefined reference to `pthread_mutex_unlock' what am I doing wrong? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building a completely static executable (using boost regex library)
Peter Johansson wrote: Hi Lorenzo, Lorenzo Bettini wrote: Hi I was trying to build, in linux, a completely static executable that uses libboost_regex; I issued configure LDFLAGS="-static" make LDFLAGS="-all-static" [...] what am I doing wrong? Are you sure you have static version of boost_regex available. A quick check on my machine (Fedora) revealed that I only have a dynamic version of boost (libboost_regex.so.1.34.1). I suspected that! the fact is that I also have libboost_regex.a and I thought that it was a static version... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building a completely static executable (using boost regex library)
Bob Friesenhahn wrote: On Tue, 14 Jul 2009, Lorenzo Bettini wrote: I was trying to build, in linux, a completely static executable that uses libboost_regex; I issued configure LDFLAGS="-static" make LDFLAGS="-all-static" but when it comes to linking I get this error: /bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -L/usr/lib -all-static -o check-regexp check-regexp_cmd.o check-regexp.o -lboost_regex ../gl/libgnu.la libtool: link: g++ -g -O2 -static -o check-regexp check-regexp_cmd.o check-regexp.o -L/usr/lib -lboost_regex ../gl/.libs/libgnu.a /usr/lib/libboost_regex.a(static_mutex.o): In function `boost::scoped_static_mutex_lock::unlock()': what am I doing wrong? Your project is lacking a dependency on the thread library. When static linking, all the libraries that your library depends on need to be listed. it looks like stdlib depends on that, but I thought there was a static version of that too... also libboost_regex seems to depend on that... how can one know all the libraries to link to? I'm using autotools, and I thought that it would take care of that... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
versioning and soname
Hi from what I understand, at least in a Unix environment, if the library version is current:revision:age the soname will be (current-age).age.revision won't it? Now if I have a library version (the revision should not be important in this context) 5:_:4 the soname will be 1.4._ right? If I now remove an interface I should set as a library version the following one, right? 6:0:0 and this will generate a soname 6.0.0 i.e., from soname 1.4 we go directly to 6.0 is this the intended behavior? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: versioning and soname
Thanks for all your clarifying emails :-) cheers Lore -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
