Re: Problem with truetype fonts caused by not building FreeTypemodule?

[Lev S Bishop <lev dot bishop at yale dot edu>]

Harold wrote:
> Lev S Bishop wrote:
>> - the resulting module gets statically linked into libXfont.a (rather
>> than being a loadable module, as it would be in many other X servers,
>> since we don't do loadable modules on cygwin/x), and from there gets
>> linked into XWin.exe and xfs.exe (I understand xfs.exe is currently
>> non-functional, though), and perhaps some other places?
>
> Regarding the static linking, that is not correct. I had noticed
> recently that XWin.exe was no longer linked to cygfreetype-6.dll (do a
> 'cygcheck XWin.exe' to find out what DLLs are being linked to) and was
> wondering what happened.

No, I am sure that I am correct about the static linking, but I was not
very clear what I was saying. There are *two* things called "freetype"  
under discussion. There is the freetype library (the thing that is
available from www.freetype.org, is independent of X, and is contained in
cygfreetype-6.dll from the package libfreetype26-2.1.5-1) and there is the
freetype module (aka "FreeType" backend, formerly known as xfsft, this is
the thing that's part of the x server). From now on I'll call the former
freetype "the freetype2 library" and the latter "the freetype backend".  
The freetype backend deals with making truetype fonts look and feel to the
rest of the x server like all other x core fonts, XLFDs, fonts.dir,
fonts.alias, etc) but to do the actual rendering it calls upon the
freetype2 library. You can think of it as a "wrapper" for the freetype2
library. There is a version of the freetype2 library in the xc source
tree, but we don't want to use it because we prefer to use a seperately
installed (more up to date) version, so we set HasFreeType2 YES (typo in
my earlier email, missed off the 2 on HasFreeType2). The freetype2 library
can be dynamically linked (its cygfreetype6.dll).  Following me so far?
Now, here's what I was really getting at: the server architecture is such
that certain parts of the X server are loadable modules -- whether or not
they get loaded into the server is configured *at runtime* by looking in
the "Module" section of the config file (xorg.conf), for lines like 'Load
"type1"' to load the type 1 font rasterizer, etc (this is as opposed to
"load time" dynamic linking, which is what cygcheck tells you about).  
See: http://freedesktop.org/~xorg/X11R6.7.0/doc/xorg.conf.5.html#sect5
However, cygwin/x doesn't support loadable modules like that (we don't set
DoLoadableServer YES, and we don't have a config file to read even if we
did) so the freetype backend gets built statically into libXfont.a, and
libXfont.a is linked into XWin.exe.

So the path is like this for cygwin/x:
XWin.exe is linked to libXfont.a, which includes the freetype backend, 
which depends on the freetype2 library. So the ultimate situation is that 
XWin.exe is statically linked to the freetype backend but dynamically 
linked to the freetype2 library.

(With recent builds, the situation was: XWin.exe is linked to libXfont.a, 
which doesn't include the freetype backend, so nothing in XWin.exe depends 
on the freetype2 library, so cygcheck on XWin.exe doesn't report 
cygfreetype6.dll).

Whether or not we use the freetype backend is controlled by the build
switch: BuildFreeType (note capitalization). The freetype2 library is
controlled by the switch HasFreetype2. We already have HasFreetype2 YES,
but we need to add BuildFreeType YES. The switches control the building of
completely orthogonal branches of the source tree.

I hope that was clear?

Harold: you mentioned something about BuildFontconfig. There is no such 
switch. There is only a switch BuildFontconfigLibrary. This gets its 
default (correctly) due to our setting HasFontconfig YES. You don't need 
to change anything here. Anyway, we're talking about server-side fonts 
here, which don't use fontconfig. The client-side font mechanism does use 
fontconfig, and that side of things is working perfectly right now -- no 
need to mess about with that.

Lev