Re: RPM and shared library support

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Max Bowsher wrote:
> Don't just copy stuff!
> Use "libtoolize --copy --force"

Yes.

> > This is probably a very dumb question, but what's the difference between
> > cygbz2-1.dll and libbz2.dll.a (other than cygbz2-1.dll being a shared
> > library DLL, and libbz2.dll.a being in import library?)
>
>
> That *IS* the difference.

Well, yeah, but there's more to it.

Back in the dawn of time, there was cygbz21.0.dll and its import library 
libbz2.dll.a.  That is, the '2' is part of the library name, not a 
version number.  The DLL version number was '1.0' and was concatenated 
to the library name without a '-' -- thank you, stupid libbz2 Makefile.

However, the API changed (slightly) at one point, and I had to bump the 
version number.  Instead of using the (braindead) library versioning 
that was, at the time, built into the libbz2 Makefiles, I took the 
opportunity to make the DLL versioning look more like "normal" cygwin 
shared libs: cygfoo-X.dll, not cygfooX.Y.dll.

So, the new (current) release has

cygbz2-1.dll and its import library libbz2.dll.a

Note that the import name is the same as before.  This means that new 
compiles that say -lbz2 will automagically link against the new import 
lib and get the new DLL.  It is no longer possible to compile an app 
against the old DLL(*) -- and that is a good thing.  But, I put the old 
DLL into its own package so that existing programs that had ALREADY 
linked against the old DLL could still find/use it.

(*) Well, now you can actually link directly to the DLL itself and skip 
the whole import lib thing -- but that's a corner case.   Yes, you can 
use a gun to shoot yourself in the foot, but why would you want to?

--Chuck