[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] On the impact of installing the next FreeType release on a ty

From: david turner
Subject: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution
Date: Wed, 15 Feb 2006 11:38:43 +0100
User-agent: Thunderbird 1.5 (Windows/20051201)

Hello everyone,

I'd like to re-activate the debate regarding how we're going to install/name the
next FreeType release in order to avoid some of the ugly problems discussed

As far as I have understood:

* Installing the next release as "" is going to break any rogue client. Even if we provide patches for the most important ones, correct installation remains probably problematic for a typical user. and we don't control what has been compiled/
 installed locally anyway.

* Installing the next release as "" is not going to solve the problem either,

- some programs are going to be linked with both libfreetype6 and libfreetype7

- due to the way ELF dynamic linking works, erratic code paths will be taken,
   resulting in incorrect behaviour or even crashes

- some of this can be avoided if we avoid same-named functions in libfreetype6
   and libfreetype7 (e.g. using the "FT3_" prefix, instead of "FT_"),
   but there are still cases where a program obtains a FT_Face object
   through libfreetype7, then call an internal function in libfreetype6,
   later resulting in a crash.

I am a Linux user too, and believe that this behaviour is simply *unacceptable*.
We thus need a different way to solve this. Given that rogue clients do:

- call internal functions from libfreetype6 that were mistakenly exposed
  by our build system until now

- also peek/poke directly at internal fields of some FreeType objects

we must, and only can, ensure *binary* compatibility by the following:

 - first of all, install the next release as libfreetype6. RIGHT !!

 - provide the previous internal functions, or some *stubs*, in the
   new libfreetype6 library (but not from the installed headers !)

 - ensuring that the internal layout of FreeType objects in the new
   libfreetype6 is *compatible* with the ones in the old libfreetype6
   (at least recent releases, since these have changed already without
   too much problems).

Note that our goal is to prevent *crashes* from already installed applications and libraries, *not* to ensure 100% correct behaviour. In other words, it is ok to "cheat" by ignoring some request made through these "exposed" internal functions
(e.g. returning a not-implemented-error), or fill internal fields with bogus
values. it will depend on context and relative importance of each point.

And of course, the internal headers will _not_ be installed anymore, which means
that the source code of any rogue client shall be updated anyway.

to achieve this, we must:

- immediately freeze development on the current code base

- perform a massive diff between the content of "include/freetype/internal"
 between the 2.1.10 release and the current CVS, and study how we can stub
 each type, field and function defined here.

- do the required modifications, encapsulating each of the "old" internals
 in a configuration macro (e.g. FT_CONFIG_OPTION_OLD_INTERNALS)

- test, test, test, on existing installations. Preferabbly ones with old releases
 of fontconfig/libXft/Pango/Qt/etc...

- release something stable as early as possible.

Any comments ?

- David Turner
- The FreeType Project  (

Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]