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