cURL / Mailing Lists / curl-library / Single Mail


Re: Are libcurldll.a and libssh2dll.a meant to be named as such?

From: Guenter <>
Date: Sun, 18 Aug 2013 17:45:47 +0200

On 17.08.2013 05:17, K. Frank wrote:
> Thanks for the follow-up.
> I like your reasoning. I don't really know the history and reasoning behind
> the typical mingw library naming system, and hadn't realized that it limits
> one's flexibility in choosing which libraries to link statically vs.
> dynamically.
this is no typical mingw naming system but the general behaviour of
windows-targeted configure builds.

> Just to be clear, I'm not complaining or asking for any change -- the current
> system works just fine for me. I was just curious about the apparent
> inconsistency.
> Also, do I surmise correctly that the naming convention for libcurl differs
> from that of, say, libcrypto because libcrypto is a separate project that
> you just use, and you don't elect to force your preferred naming convention
> on them?
exactly; libcurl and libssh2 are under my control - OpenSSL is not.
Beside that the naming for libcurl existed already long before I took
over maintaining the static MinGW makefiles; I just kept it this way,
and I adopted it to libssh2 ...
since building OpenSSL native on Windows with MinGW is really a pain I
do cross-compile it on Linux; if I would do same for libcurl and libssh2
then the naming would be equal (*.dll.a);
but for now I stay with building the binaries (lots of different combos
which are not all listed on the download page; see ); if I would want to build these
all with MinGW configure, or even cross-compile on Linux (which would be
way faster) that would nevertheless take probably half a day - while
compilation of one combo with the static makefiles takes only ~1-2mins
(I build the win32 bins on an old 2.8MHz P4 running W2K3sp2 and the
win64 bins on a 1.8GHz 2-core Atom running W7sp1-x64) ...

I struggle enough already with configure while building Linux and
Android targets, so I dont wanna add some more for Windows targets ... ;-)

If I would want to cross-compile Windows binaries on Linux + provide
latest versions of dependencies then I would also have to:
- compile + install the dependencies into the cross compiler (bad thing
since then no longer package management works)
- build RPMs of the newer deps so that I can cleanly install/uninstall
them with the package manager (the 'right' way but a lot of initial work
until that flies for all deps)
- specify separate locations of each newer dependency (always a hard way
until this finally works as desired)


List admin:
Received on 2013-08-18