Merge bitcoin-core/secp256k1#1105: Don't export symbols in static lib…

…raries

6f6cab9 abi: Don't export symbols in static Windows libraries (Cory Fields)

Pull request description:

  For context, Bitcoin Core has recently merged [libbitcoin-kernel](bitcoin#24322), a small library that intends to eventually minimally encompass Core's validation engine. This kernel lib includes a static libsecp256k1. Without this change, because libsecp256k1.a ends up with exported symbols, we end up with libsecp256k1 symbols exported by our libbitcoin-kernel library (which causes unrelated problems not worth getting into here).

  libtool takes care of building both object versions, and it automatically builds objects for shared libs with -DDLL_EXPORT. We just need to opt-in to its functionality.

  I can't imagine this having any negative impact on any current statically-linking applications, if anything they'll just be a tiny bit smaller because they can now strip unused symbols.

ACKs for top commit:
  real-or-random:
    utACK 6f6cab9
  theuni:
    > Not sure what other changes made compilation on CI fail but Concept ACK [6f6cab9](bitcoin-core/secp256k1@6f6cab9). This should be entirely harmless.
  sipa:
    utACK 6f6cab9
  laanwj:
    utACK 6f6cab9

Tree-SHA512: 39f240046639738f7a8c01068e728b2f9ceac2754cc4b0a5fa46c28f6f57a8c4124653b56dfbf5c13106b07c11ac599cc41b508e16862d539ce1af6c3365a205

include/secp256k1.h

@@ -141,9 +141,13 @@ typedef int (*secp256k1_nonce_function)(
 # define SECP256K1_NO_BUILD
 #endif
 
+/** At secp256k1 build-time DLL_EXPORT is defined when building objects destined
+ *  for a shared library, but not for those intended for static libraries.
+ */
+
 #ifndef SECP256K1_API
 # if defined(_WIN32)
-#  ifdef SECP256K1_BUILD
+#  if defined(SECP256K1_BUILD) && defined(DLL_EXPORT)
 #   define SECP256K1_API __declspec(dllexport)
 #  else
 #   define SECP256K1_API