Re: libtool windows dll suffix revision

[Peter Rosin]

Alon Bar-Lev skrev:
> Hello,
>
> I appreciate any reply regarding this.
> The win32 build is supported in 2.2 series, and this issue remains.
>
> Regards,
> Alon Bar-Lev.
>
> On 3/9/08, Alon Bar-Lev <address@hidden> wrote:
> > Hello,
> >
> >  Please CC me as I am not subscribed.
> >
> >  Was something in the following discussion progressed?
> >
> >  http://www.cygwin.com/ml/cygwin/2000-09/msg00053.html
> >
> >  From: "Gary V. Vaughan" <gvv at techie dot com>
> >  """
> >   Libtool translates the
> >  5:4:3 into a system specific version number for the soname to help the
> >  runtime loadee choose the best available library at runtime.  As I
> >  said before, currently this mapping is wrong on Windows, and I think
> >  the correct mapping is to always use the oldest supported interface
> >  number -- in this case library2.dll -- when generating the soname.
> >  This is explained fully in the version node of the libtool manual link
> >  that was quoted earlier in the thread.
> >  """
> >
> >  For example, I have current interface 7 and age 7 i get dll-0.dll, and
> >  if I upgrade to current interface 8 and age 8 I also get dll-0.dll.

But if you have current interface 15 and age 7 you get dll-8.dll.

> >  It looks like generating the suffix version based on delta is
> >  incorrect, as you may have duplicate dll names.
> >
> >  It also looks like Gary is right,  having the version be the age
> >  solves the issue, since as long as the library is backward compatible
> >  to this age, the name is not change.

With your suggestion of always using age, you would get dll-7.dll and
dll-8.dll for your examples, but you would also get dll-7.dll for my
example, and then you would have the same file name for two incompatible
dlls, which is a lot worse than having the same file name for two
compatible dlls.

Please explain further, if I have made any false assumptions.

Cheers,
Peter