[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156
From: |
Hin-Tak Leung |
Subject: |
Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 17) |
Date: |
Sun, 14 Jan 2018 19:03:03 +0000 (UTC) |
> Date: Sat, 13 Jan 2018 19:50:23 +0100
(CET)
> From: Werner LEMBERG <address@hidden>
> To: address@hidden
> Cc: address@hidden,
> address@hidden,
> address@hidden
> But Visual C is a front-end to a
> command line compiler, isn't it? In
> that it makes sense to have this stuff
> in FreeType's header file also;
> for example, people want to call nmake
> manually...
Well, that's the same issue: Microsoft nmake is not entirely compatible with
GNU/BSD make. So you'll need a custom Microsoft-specific makefile also...
> Date: Sat, 13 Jan 2018 20:57:06 +0100
> From: Vincent Torri <address@hidden>
> To: Werner LEMBERG <address@hidden>
> Cc: Hin-Tak Leung <address@hidden>,
> Alexei Podtelezhnikov
> <address@hidden>,
> freetype-devel <address@hidden>
> 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).
That's exactly my point: the visibility atribute works on mingw gcc also. mingw
gcc and the GNU linker on windows does not need these
Microsoft-compiler-specific hacks. These hacks are microsoft-compiler-specific,
NOT generic windows-compiler-specific. Mingw gcc does not need them.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 17),
Hin-Tak Leung <=