Re: Are libcurldll.a and libssh2dll.a meant to be named as such?
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.
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
> 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
http://curl.haxx.se/gknw.net/7.32.0/ ); 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: http://cool.haxx.se/list/listinfo/curl-library
Received on 2013-08-18