Re: [ft-devel] FreeType DLL support

[Vincent Torri]

On Sat, Jan 13, 2018 at 7:50 PM, Werner LEMBERG <address@hidden> wrote:
>
>> Btw, visual studio's project/sln files can contain compiler
>> preprocessor definitions also.  You can do that FT_EXPORT redefine
>> hacks in those.  There is no need to polute the rest of Freetype
>> source/header.  The requirement is entirely visual studio specific
>> and mingw does not need it.
>
> But Visual C is a front-end to a command line compiler, isn't it?

it is.

>  In
> that it makes sense to have this stuff in FreeType's header file also;
> for example, people want to call nmake manually...

also it is necessary for applications or libraries  using freetype
that FT_EXPORT be defined to dllimport (which is currently the case).

I would like also to mention in the case of UNIX using gcc, that the
visibility of symbols can be changes by a compiler flags (remark that
there is a difference between gcc and windows compiler : on UNIX, gcc
exports all the symbols by default, which is the contrary on Windows).

so if, on UNIX, one  passes -fvisibility=hidden to gcc, FT_EXPORT
should be defined as __attribute__ ((visibility("default")))

Here is what is done in a project which I contribute to (EAPI below is
the equivalent of FT_EXPORT) :

#ifdef _WIN32
# ifdef EFL_ECORE_WIN32_BUILD   // useless in the case of freetype
#  ifdef DLL_EXPORT
#   define EAPI __declspec(dllexport)
#  else
#   define EAPI
#  endif
# else
#  define EAPI __declspec(dllimport)
# endif
#else
# ifdef __GNUC__
#  if __GNUC__ >= 4
#   define EAPI __attribute__ ((visibility("default")))
#  else
#   define EAPI
#  endif
# else
#  define EAPI
# endif
#endif

and we prepend EAPI in front of the declaration of public symbols

see https://gcc.gnu.org/wiki/Visibility for the documentation of
-fvisibility flag

Hth

Vincent Torri