[cairo] Buidling cairomm with MSVC

Andrea Canciani ranma42 at gmail.com
Mon Nov 11 02:04:16 PST 2013

On Sun, Nov 10, 2013 at 12:28 PM, John Emmas <johne53 at tiscali.co.uk> wrote:

> Hi guys,
> According to the cairomm information page, this is the correct mailing
> list for asking questions about cairomm.  I hope that information's still
> current.  I have a simple question about building cairomm with MSVC.
> After downloading cairomm from git, I can see that it contains a number of
> MSVC projects.  AFAICT the various tests tend to build exes whereas the
> libraries are mostly built as DLLs.  When building DLLs for Windows its
> common (in fact, mandatory AFAIK) to use __declspec for indicating when a
> symbol needs to get imported from a DLL.

See http://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx
__declspec(import) is mandatory for variables, but for functions it is just
an optimization which removes a jump.

>  Exporting is slightly different because a module definition file can be
> used instead of __declspec.  Indeed, I can see that the cairomm.vcproj
> files do generate a ".def" file at build time.  But it still leaves the
> problem of how an application will know that cairomm.lib is the symbols
> library for a DLL as opposed to a regular static lib.  This is the most
> common strategy... I've taken glibmm as an example because it also uses
> gendef:-
>       #ifdef GLIBMM_DLL
>         #if defined(GLIBMM_BUILD) && defined(_WINDLL)
>           /* Do not dllexport as it is handled by gendef on MSVC */
>           #define GLIBMM_API
>         #elif !defined(GLIBMM_BUILD)
>           #define GLIBMM_API __declspec(dllimport)
>         #else
>           /* Build a static library */
>           #define GLIBMM_API
>         #endif /* GLIBMM_BUILD - _WINDLL */
>       #else
>         #define GLIBMM_API
>       #endif /* GLIBMM_DLL */
> I've looked for something similar in cairomm but I couldn't find anything.
>  In fact, I couldn't find any use of __declspec at all, so how does this
> work in cairomm?

The idea is that the jump optimization is not usually needed.
If in your usage, it has a significant performance impact, could you
provide some testcases to reproduce the issue?
(I agree that a better handling of win32 DLLs would be quite desirable, but
right now I'm more concerned with other issues, like initialization and


> John
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20131111/cecea04f/attachment.html>

More information about the cairo mailing list