CURL_STATICLIB redundant?

[nschloe]

I wondered what the preprocessor setting -DCURL_STATICLIB=1 was about, but

$ grep -r CURL_STATICLIB *

only turns up the setting in CMakeLists.txt. It seems redundant.

[nschloe]

Aha, wait, from http://curl.haxx.se/docs/faq.html I'm taking

When building an application that uses the static libcurl library, you must add -DCURL_STATICLIB to your CFLAGS.

This is probably the reason why it's added. However, nothing tells CMake to actually link against CURL statically. For example, the libnetcdf.so link line looks like

/usr/bin/cc  -fPIC  -Wno-unused-variable -Wno-unused-parameter -O2 -g -DNDEBUG -shared   -shared -Wl,-soname,libnetcdf.so.7 -o libnetcdf.so.7.2.0 <all objects> -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl

[WardF]

This is a tricky one. As I recall, back when I started with cmake, I added this as default because I observed no ill effects, and determining if the curl library was static or not was difficult across platforms. On Linux platforms, for example, checking the file suffix may be sufficient, but on Windows '.lib' may either be a static library or the import library for a .dll.

A brief web search shows lots of suggestions for how to determine if a target library is static or not, but no heuristic that is bullet-proof. The solution to this may be more a question of policy. For example, this requirement may need to be documented and highlighted for developers who may be compiling netcdf themselves.

I'll probably remove this flag and leave it up to the down-stream developer to pass. I'll also document this. I'm going to close this issue out now but will leave a note when it's been resolved shortly.

[nschloe]

libcurl's comment on the necessity of this preprocessor flag is listed in the section

5.7 Link errors when building libcurl on Windows!

I'm sure this is because of the same problem that you describe: On Windows, it's hard to tell if you're dealing with a dynamic or static library. It is probably safe to wrap that flag into IF(MSVC) or IF(WIN32).