On Apr 5, 2005, at 2:43 PM, Jim Napier wrote:
> Since I upgraded to 7.13.1 from 7.11.1 and started adding
> -DCURL_STATICLIB to my cl.exe CFLAGS options, in addition to my
> app.exe file I also see an app.lib and an app.exp file that are now
> created but never used to be there. This occurs during the linking
> phase and the linker now prints out a message about creating the files
> that it didn't used to display. Here's a sample of the link command
> I'm using:
>
> link.exe -nologo -subsystem:console -machine:I386
> -out:dist/bin/app.exe object1.obj object2.obj libcurl.lib
>
> Any idea why this changed? And what is the significance of the new
> files?

Okay, I finally figured this out. Basically, libcurl wasn't following
it's own advice and wasn't using /DCURL_STATICLIB when building itself.
  Here's the bit in curl.h:

/*
  * Decorate exportable functions for Win32 DLL linking.
  * This avoids using a .def file for building libcurl.dll.
  */
#if (defined(WIN32) || defined(_WIN32)) && !defined(CURL_STATICLIB)
#if defined(BUILDING_LIBCURL)
#define CURL_EXTERN __declspec(dllexport)
#else
#define CURL_EXTERN __declspec(dllimport)
#endif
#else
#define CURL_EXTERN
#endif

You'll notice that functions get exported even when building a static
library (since BUILDING_LIBCURL is always set). These functions
somehow get embedded into your .exe and thus also exported by your
.exe. In any case, I think Makefile.vc6 needs to set CURL_STATICLIB
when it builds static library variants. I've attached a patch to
lib/Makefile.vc6 that should do this.

Note: I haven't test every build variant (just a top-level "nmake vc")
and I may have forgotten some. I tried to find every target that used
$(LNKLIB) and then also append $(CFLAGSLIB) to it's CC. I chose the
name CFLAGSLIB since these are CFLAGS that should be used when building
a .lib.

-Dave