Use explicit symbol visibility.

[gmaxwell]

The use of static makes this somewhat redundant currently, though if
we later have multiple compilation units it will be needed.

This also sets the dllexport needed for shared libraries on win32.

[gmaxwell]

Fixes #305

[sipa]

Just to get this straight: -fvisibiblity changes the visibility across library boundaries, while static changes the visibility across module boundaries?

[sipa]

@theuni Comments?

[theuni]

Looks good to me. This replaces #223, but I like this approach better.

Only thing I'm iffy about is the win32+static case, where we won't want to set dllexport. libtool automatically sets -DDLL_EXPORT when building for a dll, I think we could take advantage of that like:

#  if defined(SECP256K1_BUILD) && defined(DLL_EXPORT)
#   define SECP256K1_EXPORT __declspec(dllexport)
#  else

[gmaxwell]

@sipa Yes. static, as a side-effect, makes things invisible across a library boundary. But it does so by making it invisible across module boundaries. Right now, since the library is a single C file, static is sufficient. But win32 wants explicit visibility for libraries in all cases (either via a symbol file, or via the dll annotations this also adds), and we might want multiple modules in the future.

@theuni Probably the most interesting/challenges cases for DLL building are when people are using an alternative build system, though I suppose they could just set DLL_EXPORT too. What does setting dllexport on a win32 static do? I don't think I've ever seen any complaints from setting it there. If it's harmless-- might as well set it.

[theuni]

@gmaxwell presumably it would export libsecp256k1 functions from resulting binaries and helper libs.

[theuni]

@gmaxwell poking around with mingw, I can't manage to produce that result, so disregard the comment above. We can revisit if it ever surfaces.

[theuni]

whoops, s/WIN32/_WIN32/.

WIN32 isn't picked up by my mingw install.

[gmaxwell]

@theuni Good spot. I think on many (?!) build environments both are set, but _WIN32 seems clearly safer. Updated.