Opened 15 years ago

Closed 15 years ago

#2518 closed task (fixed)

Xorg-7.2 libXfont

Reported by: Randy McMurchy Owned by: dnicholson@…
Priority: normal Milestone: 6.3
Component: BOOK Version: SVN
Severity: normal Keywords:

Description (last modified by Randy McMurchy)

This isn't an actual issue. I had problems compiling the bdftopcf program in XorgApps because what turns out to be an issue with libXfont. On Christmas Day last year, DJ removed parts of the Wiki that deals with the exact issue I see.

* NOTE: the system having this issue does not have BLFS-SVN packages installed, nor is it even close to an LFS-6.2 system. It is a recently built system using LFS SVN and many updated BLFS packages including FreeType and Fontconfig. *

Anyway, the relevant text removed from the Wiki is this:

My Questions:

  1. I'm wondering what is the root reason why this issue exists?

(package versions probably?) I did not try to search the mail archives for this issue.

  1. Why was that text removed from the Wiki? If it wasn't

relevant to current BLFS-6.2, then we probably should leave stuff like that, but add a description or something that it only happens in XYZ configuration (or whatever).

  1. We should use the comment facility when changes such as this

are made to the Wiki so that you don't have to search mail archives or something else to find out why the change was made.

Please don't hesitate to close this ticket. I marked it for 6.3 simply so there may be a reply and it stays in queue.

Attachments (2)

libXfont-fix-macro-1.2.8.patch (2.0 KB ) - added by dnicholson@… 15 years ago.
Fix libXfont to work with newer freetype
libXfont-update-1.3.2.patch (3.7 KB ) - added by dnicholson@… 15 years ago.
Update libXfont to work with newer freetype

Download all attachments as: .zip

Change History (17)

comment:1 by dnicholson@…, 15 years ago

I don't know the entire history here, but I think the problem is that there is a freetype macro ft_isdigit that's included in one of the freetype headers. The problem is "fixed" in libXfont-1.3.1 because the code which used ft_isdigit was removed. But this definitely should work with libXfont-1.2.8 and bdftopcf-1.0.1. Looking at bdftopcf, though, I'm not really sure how it manifested this issue, though.

Any chance you can show the error building bdftocpf and let me know what versions of libXfont, freetype and bdftopcf were in use? I'm guessing that we might just need to kludge in an #include in libXfont to ensure this always works.

comment:2 by Randy McMurchy, 15 years ago

I'm now past this issue, and cannot exactly reproduce it as I've since updated the version of libXfont to 1.3.0 and it seems to work fine (I've not tested the X installation yet, I'm still building packages).

I can say that it was the ft_isdigit issue exactly as described in the Wiki page I mentioned. Here are the specifics when the issue occurred:

x86-64 building in 32bit mode Very current LFS-SVN Linux- FreeType-2.3.5 Fontconfig-2.5.0 Xorg-7.2 packages using BLFS-SVN wget file

I updated libXfont to 1.3.0 and the issue went away. Let me know if you want more info. One of the reasons I built Xorg-7.2 instead of 7.3 was to see how it would build in an imaginary scenario where you used LFS-SVN and some minor updated BLFS packages, but stuck with the Xorg-7.2 instructions as they stand right now (which is probably close to how they will be in the 6.3 release).

comment:3 by Randy McMurchy, 15 years ago

Description: modified (diff)

Updated the description to change very relevant material

comment:4 by dnicholson@…, 15 years ago

For bdftopcf vs. libXfont-1.2.x/libXfont-1.3.x, I'd like to understand the error more before closing this. For installing libXfont-1.2.x vs. libXfont-1.3.x, 1.3.x should be fine on either Xorg. The reason I didn't push in the update is because libXfont-1.3.x has a big new feature, which is neat, but different than the libXfont from Xorg-7.2:

The part I don't get is how compiling bdftopcf could make the linker throw that error. I would have expected it to be seen when compiling libXfont. I suppose that if the compiler didn't know that ft_isdigit was a macro (the needed freetype header wasn't included), it would just bind it into libXfont as a symbol that it would expect to be resolved at runtime. If the macro had been resolved correctly when compiling libXfont, then the symbol in libXfont would be isdigit or ctype_b_loc (if isdigit is a macro, too). And that's what I see if I build libXfont-1.2.8 against freetype-2.3.4:

$ nm src/.libs/ | egrep '(isdigit|ctype_b)'

U ctype_b_loc@@GLIBC_2.3

Now I found the problem. It's in freetype-2.3.5 where they stopped defining the ft_* macros:

diff -pNur /usr/include/freetype2/freetype/config/ftstdlib.h dest/usr/include/freetype2/freetype/config/ftstdlib.h
--- /usr/include/freetype2/freetype/config/ftstdlib.h   2007-04-23 14:27:00.000000000 -0700
+++ dest/usr/include/freetype2/freetype/config/ftstdlib.h       2008-04-28 11:04:03.000000000 -0700
@@ -78,15 +78,6 @@

-#include <ctype.h>
-#define ft_isalnum   isalnum
-#define ft_isdigit   isdigit
-#define ft_islower   islower
-#define ft_isupper   isupper
-#define ft_isxdigit  isxdigit
 #include <string.h>

 #define ft_memchr   memchr

comment:5 by dnicholson@…, 15 years ago

Owner: changed from blfs-book@… to dnicholson@…
Status: newassigned

So, there are three solutions to make sure our libXfont stays compatible with freetype:

  1. Update to libXfont-1.3.x where the code that uses these macros has been removed.
  1. Patch libXfont-1.2.x so that it falls back to defining ft_isdigit when it's not defined by freetype. The code is already partially there, it's just conditional on a really old freetype version. We just need to make it unconditional on freetype version.
  1. Patch freetype-2.3.5 to put the ft_* macros back in ftstdlib.h. This is probably the right thing to do since those macros were part of the freetype API and were removed without notice. But I don't know if we want to differ from upstream in that regard.

comment:6 by bdubbs@…, 15 years ago

What are the drawbacks to installing libXfont-1.3.x?

To me, that is the preferable route. We will be doing that eventually anyway.

comment:7 by dnicholson@…, 15 years ago

Only that it hadn't been tested w.r.t Xorg-7.2. I think it should be fine, and it contains the security fix that's in the book now. It just goes against the policy I'd been using for Xorg modules where I was updating only if the patchlevel (the z in x.y.z) had changed and not the major or minor.

comment:8 by bdubbs@…, 15 years ago

Policies are general rules. Deviations for reasonable situations are OK. If you think it won't break anything, I say go ahead.

comment:9 by DJ Lucas, 15 years ago

Milestone: 6.3future

comment:10 by dnicholson@…, 15 years ago

Are you sure we want to push this off to the future? It's inevitable that someone will use freetype-2.3.5, and when they do, some components can no longer build with libXfont-1.2.8. I think we need to address this with one of the solutions I outlined above for 6.3.

comment:11 by DJ Lucas, 15 years ago

Milestone: future6.3

by dnicholson@…, 15 years ago

Fix libXfont to work with newer freetype

by dnicholson@…, 15 years ago

Attachment: libXfont-update-1.3.2.patch added

Update libXfont to work with newer freetype

comment:12 by dnicholson@…, 15 years ago

Two patches to fix this issue. Choose one :)

comment:13 by Randy McMurchy, 15 years ago

I will defer to your good judgement. :-)

(besides, DJ is probably the one most qualified to work with you on this one, or at least offer an opinion)

comment:14 by dnicholson@…, 15 years ago

Right now I'm leaning towards just doing the sed on libXfont-1.2.8. That's the version that's been in SVN for a long time.

comment:15 by dnicholson@…, 15 years ago

Resolution: fixed
Status: assignedclosed

Applied the first patch, which just uses an sed to replace usage of ft_isdigit with isdigit. See r7432.

Note: See TracTickets for help on using tickets.