Re: printing library version

[Jason Curl]

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
>
>