Use explicit symbol visibility. #312

1. 
   gmaxwell commented at 8:00 pm on September 20, 2015: contributor

   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.

2. Include public module headers when compiling modules.

   Also fix the nullness requirements for schnorr nonce-pair generation.

   c2ef56a116
3. Use explicit symbol visibility.

   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.

   ca7cb4c7d8
4. 
   gmaxwell commented at 8:00 pm on September 20, 2015: contributor

   Fixes #305
5. 
   sipa commented at 7:05 pm on September 21, 2015: contributor

   Just to get this straight: -fvisibiblity changes the visibility across library boundaries, while static changes the visibility across module boundaries?
6. 
   sipa commented at 7:11 pm on September 21, 2015: contributor

   @theuni Comments?
7. 
   theuni commented at 8:08 pm on September 21, 2015: contributor

   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:

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

8. 
   gmaxwell commented at 8:11 pm on September 21, 2015: contributor

   @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.
9. 
   theuni commented at 8:13 pm on September 21, 2015: contributor

   @gmaxwell presumably it would export libsecp256k1 functions from resulting binaries and helper libs.
10. 
    theuni commented at 8:37 pm on September 21, 2015: contributor

    @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.
11. 
    theuni commented at 9:09 pm on September 21, 2015: contributor

    whoops, s/WIN32/_WIN32/.

    WIN32 isn’t picked up by my mingw install.

12. 
    gmaxwell commented at 9:41 pm on September 21, 2015: contributor

    @theuni Good spot. I think on many (?!) build environments both are set, but _WIN32 seems clearly safer. Updated.
13. gmaxwell closed this on Sep 21, 2015

    ---

14. gmaxwell deleted the branch on Sep 21, 2015
15. gmaxwell cross-referenced this on Sep 21, 2015 from issue Use explicit symbol visibility. by gmaxwell

Contributors
gmaxwell sipa theuni