Hi,
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
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)
or:
- 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)
or:
- specify separate locations of each newer dependency (always a hard way
until this finally works as desired)
Gün.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html