[Proj] Proj 4.9.1RC4 shared library on Windows
charles.karney at sri.com
Tue Mar 3 22:30:05 EST 2015
Seen from a Unix perspective, Windows' handling of shared library seems
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
> 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
More information about the Proj