[Proj] Proj 4.9.1RC4 shared library on Windows

[Charles Karney]

Seen from a Unix perspective, Windows' handling of shared library seems
unduly complicated.

I'm only familiar with the style of placing a macro, e.g., LIB_EXPORT,
in front of every symbol that needs to be visible in the dll.
LIB_EXPORT expands to

* nothing for static libraries and for non-Windows machines
* __declspec(dllexport) when compiling a Windows shared library
* __declspec(dllimport) when compiling a function that will link against
   the Windows shared library.

Note that it is necessary for packages that depend on the library to
make sure that LIB_EXPORT is defined correctly (and this will in turn
depend on whether the library is shared or static).  cmake makes the
ensuing convolutions relatively painless.

However, proj puts a list of exported symbols into proj.def and cmake
evidently recognizes this file.  Unfortunately, I don't know what, if
anything, needs to be done by a dependent package.  Nevertheless, as far
as I can tell, building the shared library on Windows works fine.

On 03/03/2015 07:53 PM, Greg Troxel wrote:
>
> nicolas david <ericnico.david at gmail.com> writes:
>
>> Being the guy behind proj4-cmake old repository I supect to be also the guy
>> who wrote this warning.
>> If a remember well is due to the fact that nad2nad and nad2bin include
>> "project.h" and not "proj_api.h". So as on windows dll only include
>> (export) symbol defined in proj_api.h ( more precisely in proj.def) I was
>> thinking that when you include "project.h" it's better to link to static
>> lib in order to have all symbol defined.
>>
>> I'm note 100% of this fact and I could be wrong but I think it was the
>> explanation of this warning.  Looking deeper in the code it seems that
>> nad2bin only use struct defined in project.h and not function so it could
>> work.
>
> I do not understand windows linking, but this seems odd to me.  It would
> seem that dynamic vs static linking of libraries in an executable should
> not affect the behavior, or there's a bug.
>
> What the shared library exports, and what is in scope for the compiling
> program are at least on Unix separate issues.  What's exported are
> global variables in the implementation of the library.  What's in scope
> to use are declarations from the .h.   Sane practice is to compile the
> implementation against the same .h (at least).
>
> Linking to a library that doesn't defined all the used symbols should
> fail, whether done static or dynmaic.
>
> (But if this affects only Windows, then I have only minor academic
> curiousity.)