libcurl on win32

[fez]

Hey, I was wondering if you have ever compiled Unreal 3.2.1 on win32 with ziplinks, ssl, and libcurl/c-ares enabled?

If so I have a question about libcurl...

As you no doubt know, it's a bitch to install...
I changed the default libc's to single threaded for both libcurl and cares, and I removed that weird free_whatever.c file from the libcurl project (the file that no longer exists), and i added ares_version.c and ares_cancel.c to the project, and I defined USE_ARES or whatever it was in the config_win32.h, and changed curl/multi.h's #include <winsock2.h> to #include <winsock.h> (to avoid errors with unreal which (when using IPv4) uses winsock 1.1).
so libcurl with c-ares compiles, but i get libcurl.dll but not libcurl.lib as an output... so it makes it impossible to link wircd....

Any help??
What process did you take to make it work?

btw, it's c-ares 1.2.0, libcurl 7.12.0, MSVS .net 2003, zlib 1.2.1 and openssl 0.9.7d

Well talk to ya later
-- Eric / fez

[fez]

a note to any of you who may be having trouble compiling unreal w/ libcurl on win32:


the .dsp file included in libcurl is not maintained and needs a lot of work!! When i open it in visual studio, it automatically generates a newer .sln file, but a few things need to change:

for one thing, it doesn't export symbols into libcurl.dll (from libcurl.def), so you need to add /DEF:libcurl.def to the linker command line.
Also you need to add /I and /LIBPATH for your c-ares include and lib path.....

good luck
-- fez / Eric

[codemastr]

Well seeing as how I'm the one who compiled the libcurl we use for win32 builds, let me say, I didn't do half of that stuff. I NEVER added any /DEF option, it generated the dll just fine. And it created the lib as well. In fact, the MSVC++ linker will *always* generate a .lib when creating a dll. For compile time linking, a dll is useless without a .lib. If you compile Unreal on win32, you'll notice in src/modules you get m_*.lib for each file, because that's just what MSVC++ does.

[aquanight]

MSDN seems to disagree...

The /IMPLIB option overrides the default name for the import library that LINK creates when it builds a program that contains exports. The default name is formed from the base name of the main output file and the extension .lib. A program contains exports if one or more of the following are specified:

• The __declspec(dllexport) keyword in the source code
• EXPORTS statement in a .def file
• An /EXPORT specification in a LINK command

LINK ignores /IMPLIB when an import library is not being created. If no exports are specified, LINK does not create an import library.

[codemastr]

Yeah, well read closer:

EXPORTS statement in a .def file

The .def file does contain an EXPORTS statement, and therefore it builds a .lib. No, of course it wouldn't build a .lib if it were a resource dll, but that's not what we are referring to.

[aquanight]

I was referring to this particular statement:

In fact, the MSVC++ linker will *always* generate a .lib when creating a dll. For compile time linking, a dll is useless without a .lib.

Yet MSDN (and your post after it ) says LINK does NOT always generate a .lib.

Of course, there is one other time when LINK doesn't drop a .lib, and that's when it also doesn't drop a .dll (linker errors ;p )! Of course, that doesn't apply in this particular case .