Re: library versioning
* Matěj Týč wrote on Tue, Feb 03, 2009 at 11:15:10AM CET: > > This is not possible, in general. It has nothing much to do with > > libtool either, because typically it's just the system semantics that > > allow for only one unversioned soname symlink. > > OK, but an easy check whether I can safely link with the lib would be > nice, too. Well, a feature check would be more in line with Autoconf "philosophy" than a version-based one, I guess. True, this is less applicable for the large software stacks that desktop apps typically use, than e.g., for the numerical libraries where often, several different implementations exist that provide (nearly) the same API. > > Of course, if you don't have to be able to have multiple versions > > installed concurrently, then all you do is use a configure test like > > AC_CHECK_LIB or sisters with the latest-added symbol that you need, > > or a self-written link test if the latest needed API isn't > > distinguishable by function symbol alone. > > Another point of having a AC_CHECK_LTLIB - like macro would be a > possibility to check whether the version of the library is OK. > Sometimes it is not possible to use AC_CHECK_LIB to check whether a > function is in the library (due to calling convention). Are you hinting at C++ here? Somebody should write a decent check for C++ libraries. Or maybe one exists already out there, dunno. > Well, I just wonder what is the sense of the libtool's versioning > system since it can't be used by library users :-) It can be used. However, library versioning is primarily a concept to allow support of existing binaries. Recompiling is intended to always work against the newest versions of things. A corollary is that, when you are building software in order to distribute it in binary form, then build it against the oldest versions of the libraries that you want to be compatible with. At least that is the way it was originally intended, I think. I should admit that, in principle, libtool could go beyond that and support some sort of linking against older library versions; on some systems, this could work. But we try not to promote semantics that are unportable. And anyway there is no analogous functionality in the preprocessor: for included headers, there exists no agreed-upon versioning concept, and you typically cannot mix those from different versions either. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Where to generate .lo files ?
Hello Michel, * Michel Briand wrote on Tue, Feb 03, 2009 at 06:09:11PM CET: > > I wonder if it's possible to tell libtool to generate .lo file > elsewhere than in source directory (where Makefile resides). Yes: libtool --mode=compile $CC -o some/where/foo.lo -c else/where/foo.c If you're using Automake, then you're probably looking for the Automake option subdir-objects, which causes objects to put in directories along the subdir of the source files provided. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Where to generate .lo files ?
Hi all, I wonder if it's possible to tell libtool to generate .lo file elsewhere than in source directory (where Makefile resides). Best regards, Michel -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to link with libtool?
On Tue, 2009-02-03 at 11:05 +0100, Matěj Týč wrote: > > Yes, it may be a good idea if somebody wrote this. > > It should probably depend on LT_OUTPUT. > > > > OTOH, the havelib module from gnulib already provides quite a bit of > > functionality in this area. > > OK, but what should I tell to the library users? Using gnulib is quite > troublesome since > it does not have proper documentation and usage of the library would become > too > complicated for a casual programmer. > And I don't like pkg-config since it breaks cross-compilation... Just for reference, pkg-config should not break cross-compilation after the addition of sysroot support to it. I keep meaning to look into sysroot support for libtool too, I just haven't had the time yet :(. Cheers, Richard -- Richard Purdie Intel Open Source Technology Centre ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: library versioning
Thank you for your reply, Ralf > This is not possible, in general. It has nothing much to do with > libtool either, because typically it's just the system semantics that > allow for only one unversioned soname symlink. OK, but an easy check whether I can safely link with the lib would be nice, too. > Of course, if you don't have to be able to have multiple versions > installed concurrently, then all you do is use a configure test like > AC_CHECK_LIB or sisters with the latest-added symbol that you need, > or a self-written link test if the latest needed API isn't > distinguishable by function symbol alone. Another point of having a AC_CHECK_LTLIB - like macro would be a possibility to check whether the version of the library is OK. Sometimes it is not possible to use AC_CHECK_LIB to check whether a function is in the library (due to calling convention). Well, I just wonder what is the sense of the libtool's versioning system since it can't be used by library users :-) Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to link with libtool?
> Yes, it may be a good idea if somebody wrote this. > It should probably depend on LT_OUTPUT. > > OTOH, the havelib module from gnulib already provides quite a bit of > functionality in this area. OK, but what should I tell to the library users? Using gnulib is quite troublesome since it does not have proper documentation and usage of the library would become too complicated for a casual programmer. And I don't like pkg-config since it breaks cross-compilation... So if I understand correctly, do I have to check for existence of /usr/lib/libfoo.la and then write maude_LDADD = /usr/lib/libfoo.la in my Makefile.am? ___ http://lists.gnu.org/mailman/listinfo/libtool