[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, I
From: |
Hin-Tak Leung |
Subject: |
[ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12) |
Date: |
Fri, 12 Jan 2018 17:26:37 +0000 (UTC) |
> Hi All,
> As you might have noticed, FreeType 2.9
> has added some support for building
> DLL using Visual C 2010 and above but
> unfortunately somewhat broke static
> libraries on that platform (http://savannah.nongnu.org/bugs/?52843).
> Basically, we need to hide those
> dllimport/dllexport attributes from
> anything but DLL context. So I
> suggested FT2_LINK_DLL compile-time macro
> because I like it to scream DLL and I
> did not like other ideas from
> http://geoffair.net/ms/declspec.htm.
> Here the proposal:
> #ifdef _MSC_VER
> #if defined( FT2_BUILD_LIBARY )
> && defined( _DLL )
> #define FT_EXPORT( x )
> __declspec( dllexport ) x
> #elif defined( FT2_LINK_DLL )
> #define FT_EXPORT( x )
> __declspec( dllimport ) x
> #endif
> #endif
> From my reading, FT2_LINK_DLL is
> actually optional but would optimize the
> library calls
The dllimport/dllexport stuff is a rather bizarre windows thing - basically the
compiler needs to use the library header differently, depending on whether the
header is used by the client (i.e. an application using freetype, to find the
routine elsewhere) or by the library itself (declaring a routine as being
avaiable for others' use).
An alternative to the dllimport/dllexport mechanism is to use an explicit
symbol export list. i.e. what "builds/exports.mk" does. If it is possible to
run nmake on that to build an export list?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12),
Hin-Tak Leung <=