Tor Lillqvist wrote:
What exactly do you mean with "library version" ? Note that neither
the libtool triple current:revision:age nor the Linux-style suffix it
causes to be appended after the ".so" correspond to the actual version
number for most libraries.
Isn't it simplest to just pass a -DMYLIB_VERSION="a.b.c.d" when
compiling and then have a function
Well I've always needed to get the filename (somewhat related to the
library version) when building Windows DLLs that I can prepare a
resource.in file, that will be substituted with the filename and the api
version with a self generated build number (e.g. from SVN). I end up
having to repeat what actually exists in the macros in my own macro
because there's no "function" I can call to get this information,
probably because this is entirely handled within libtool. Then a
non-autoconf tool can use Windows Resources to get the (lib api) version
also and determine if it's compatible alongside the libtool rules for R:C:A.
const char *
mylib_get_version(void)
{
return MYLIB_VERSION;
}
or something like that?
--tml
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.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
