Freetype-2.3.7 update in 6.3?

Dan Nicholson dbn.lists at
Fri Jul 11 06:43:37 PDT 2008

On Thu, Jul 10, 2008 at 8:57 PM, DJ Lucas <dj at> wrote:
> Ken Moffat wrote:
>>  Thanks for the details.  I can't reproduce the failure to build
>> bdftopcf with what I think is a now slightly old 6.3 system
>> (libXfont-1.2.8, bdftopcf-1.0.1) with the upgraded freetype.
>>  I'm unsure where to go from here, it looks as if I might have broken
>> trunk as well as 6.3, for some combination of packages ?
> I'm not sure, I only know that it *was* a problem.  Again, I'm only
> guessing from Dan's original comments, to reproduce, you'd have to
> rebuild both libXfont and bdftopcf.  I should have the time to do a
> little testing Saturday night, after the rugrats crash, if you or
> anybody else can't get to it before then.

Ah, the stupid freetype API break. Just to quickly rehash, the problem
is that freetype removed the ft_is* macros from one of the public
headers. If you were compiling an executable that was trying to use
these macros, the compiler would just barf immediately because they
would be unresolved symbols. However, when you build a library, the
compiler and linker assume that unresolved symbols will just be
resolved at runtime from some other library. In this case, the missing
ft_is* macros don't become a problem until trying to build the
bdftopcf executable. If you want to trigger this right away, set
LDFLAGS="-Wl,--no-undefined" when building libXfont-1.2.8.

We fixed this in libXfont by replacing the ft_isdigit macro by the
ctype equivalent. Now, the question is whether any other
freetype-using library or application uses any of the ft_is* macros.
I'm gonna lean towards no. It's been over a year since freetype
removed those macros, and there's been no mention that I can see on
their mailing list. Furthermore, if there are other packages where
this becomes a problem, it will be very easy to identify and fix the
problem now that the issue is understood.

So, I'd say, make the update. Fixing security vulnerabilities and bugs
is probably more important than worrying about this silly API break
that apparently no one else cares about.


More information about the blfs-dev mailing list