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

Reply via email to