libtool
[Top][All Lists]
Advanced

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

Re: Libtool -release and static libraries.


From: Brendon Costa
Subject: Re: Libtool -release and static libraries.
Date: Thu, 16 Feb 2006 16:22:24 +1100
User-agent: Thunderbird 1.5 (Windows/20051201)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter O'Gorman wrote:
> Since you seem to want libatcppunit-1.0.6 to be the library name, I suggest
> that you use it as the library name :)
> 
> lib_LTLIBRARIES = libatcppunit-1.0.6.la
> 
> This means that the libatcppunit.so symlink will also disappear (but that's
> what you want, right?) and you'll have to use -latcppunit-1.0.6 to link the
> library.

Thanks for the response and suggestions.

What you mentioned above is partly what I want to do yes, however
having a symlink to libatcppunit.a would also be a good thing so
"casual" users that only install a single version of the library do
not have to use -latcppunit-1.0.6 I had thought about renaming the
library as you mentioned above, but there are problems associated with
doing that.

In particular I have a version for the project specified in a single
place in my configure.ac file. The idea is that if I need to change
the version of the library, then I change this single value and the
rest of the project updates when I do a bootstrap configure and make.

The configure script exports the following two variables for use in
automake that help with versioning:

        PACKAGE_VERSION  1.0.6
        PACKAGE_VERSION_UNDERSCORE  1_0_6


However in the automake files I am unable to use these variables for
substitution on the left side of the = sign. I.e:

address@hidden@.la

address@hidden@_la_CPPFLAGS=-I$(top_builddir)/src
...


Fails to work. So this means I need to specify the values manually:

lib_LTLIBRARIES=libatcppunit-1.0.6.la

libatcppunit_1_0_6_la_CPPFLAGS=-I$(top_builddir)/src
...


This defeats the purpose of having the version specified in a single
place, and introduces the possibility of version mismatch between the
version used for the install file names and the version numbers used
in the compiled code.

I was hoping that I could use the -release option to do this and was
very surprised that the functionality was not consistent for both
dynamic and static libraries.


> 
> The other alternative is for us to change libtool so that static libraries
> are versioned and symlinked like shared libraries, but I don't think that
> the way to go.
> 
Is there any reason why changing this functionality in libtool would
be a bad idea? I am not involved enough with libtool to see what
re-percussions it could have. I can say that it would be the preferred
option in my situation, however maybe not for everyone. It also seems
to me as though modifying the name of both the static and dynamic
libraries is how the -release flag is supposed to operate, I do not
see why you would wish to rename one type of library and not the other.

Anyhow, Thanks again for the reply.
Brendon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD9AwQPfREiUgoLqwRAltmAJ9ouuln0UCoj/S9ixAaYs1h6JmD4ACfdpFE
S+kV1SjhjudainEiR6o3xyE=
=BfnK
-----END PGP SIGNATURE-----




reply via email to

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