Mathew Simon wrote:

> This is a newbie question. I am able to compile libcurl with SSH2 and
> create the "libcurl.dll" on the Windows platform. Till today, I was
> using the "libcurl-4.dll" found in the Win-XP binary distribution
> available at the CURL web site.
>
> Why these two "dlls" are having different names? Should I need to rename
> my "libcurl.dll" to "libcurl-4.dll" before using it with my application
> or can I use it as it is (without renaming it).

The -4 is the ABI version number. It is the filename you should get if
you build with POSIX tools, i.e. MinGW/MSYS/libtool. If you use the MS
toolchain and Win32 makefile you probably get just libcurl.dll.

The reason for including the ABI version as part of the filename is so
that you can have multiple versions of the library installed at the same
time. This is an absolute necessity for distributions where you have a
number of packages compiled against a curl/libcurl package. When the
library interface changes (ABI bump) you need to be able to release a
new libcurl without having to recompile all the old packages, which
means you need to have the ability to have multiple versions installed.
This is impossible if the library is just called "libcurl".

But this is traditionally a concern of these POSIX environments where
there is a standardized filesystem (like /usr/lib) and an explicit
package management system (such as RPM/DEB/etc.) The Windows tradition
is the wild west, every program for itself, no rules. Here the
installer usually just copies whatever version of the library the
application needs, and every application ships with its own copy -- no
sharing of shared libraries. It's unfortunate that the de facto
standard is chaos, but that's the reality.

It would be nice of you as a convenience to your users to include the
ABI version as part of the library's filename, as it is still possible
to have conflicts between projects -- this happens if you have a
brain-dead installer that copies unversioned libraries into
%WINDIR%\System32, or if the user adds the app's directory to PATH,
which exposes its DLLs to potentially be searched during process startup
for all processes.
Received on 2007-08-19