[Drat...I now want to reply to two threads at once...need more sophisticated list software...have copied Martin's post in part below from the other thread.]

On Wed, 19 Jan 2005, Alexander K.Hansen wrote:

On Jan 19, 2005, at 7:16 PM, Viv Kendon wrote:

On Mon, 10 Jan 2005, Martin Costabel wrote:

Jean-Fran�ois Mertens wrote:

[]
Probably the configure script checks directly for freetype/freetype.h,
and gets (with xorg) an error msg that one should include ft2build.h ...

Yes, it seems the freetype guys solved the compatibility problem with freetype1 that came from the standard ambiguous <freetype/freetype.h> include by making freetype2 incompatible with itself. These guys are truely crazy.


The freetype/freetype.h header that throws the error because ft2build.h was not included before actually has

#include <ft2build.h>

some lines later. So the error is only there to annoy us, it has no other function. Maybe we should just shoot them.

I can report that, if I give xpdf enough hints:

SetCPPFLAGS: -DFT_FREETYPE_H -I/usr/X11R6/include
SetCFLAGS: -DFT_FREETYPE_H -I/usr/X11R6/include
SetCXXFLAGS: -DFT_FREETYPE_H -I/usr/X11R6/include

(the first to stop it complaining about not including ft2build.h, and the second so it actually finds ft2build.h when it does try to include it a few lines later...)
then it will build against Xorg without any important looking errors or warnings(*).


Which is just to confirm your diagnosis, and demonstrate that there is nothing else wrong with my system causing problems. Of course, this is NOT the way to fix it...
[]

(ccing Victor, who posted concerning this on -beginners)

Viv's environment settings worked for me, too.
If it still builds vs. Apple's X11 with these modifications, then this might well be an option.
[]

%% Martin from ssl-ttf and ft2build.h error thread:
%% %% This is the same error. It is now verboten to use
%% %% #include <freetype/freetype.h>
%% %% which used to be the standard entry point for freetype, versions 1 and 2,
%% until version 2.1.6, that everyone was using and apparently is still using.
%% One has to use now
%% %% #include <ft2build.h>
%% #include FT_FREETYPE_H
%% %% where the first line needs -I/usr/X11R6/include and the second one
%% -I/usr/X11R6/include/freetype2.
%% %% I wouldn't trust Viv's hack to go very far without trouble, because the
%% freetype2 headers rely on FT_FREETYPE_H to be defined as
%% '<freetype/freetype.h>', whereas the hack defines it as '1'. It is then at
%% the discretion of the preprocessor which one of the two definitions it
%% takes. If we want to go this route, we would need to use
%% -DFT_FREETYPE_H='<freetype/freetype.h>', I think.
%% %% I would opt for fixing the bug at its origin, namely the arbitrary
%% incompatibility code inserted in freetype/freetype.h versions 2.1.7 and
%% above. If we remove or comment the error code
%% %% #ifndef FT_FREETYPE_H
%% #error "`ft2build.h' hasn't been included yet!"
%% #error "Please always use macros to include FreeType header files."
%% #error "Example:"
%% #error " #include <ft2build.h>"
%% #error " #include FT_FREETYPE_H"
%% #endif
%% %% from that file, no harm is done, but the errors go away.


I tried this fix for xpdf: commented out those lines in my Xorg copy of ftbuild.h -- it is then only necessary to add

SetCPPFLAGS: -I/usr/X11R6/include
SetCXXFLAGS: -I/usr/X11R6/include

for it to build properly. This is because of the way the configure script works, so I suppose the "correct" way to fix it is not these flags, but to patch the configure script (which already has some patch applied to it).

Thanks to Martin for explaining how this works (and for supporting me in my view that my original suggestion is not a good way to fix it).

Actually, one could argue the "correct" (but overburdensome) fix could be to patch every occurance of freetype.h wanting freetype2 into ftbuild.h (and modify a few paths and flags accordingly), until the upstream code changes. Martin's suggestion is definitely more practical, and minimal changes (especially directly to the code) are much easier to maintain. OTOH, we contribute to prolonging the incompatibility if we hide the error. Since fink is a porting system, not code development, perhaps it is not our job to worry about this...

-- Viv
------------------------------------------------
Dr Viv Kendon               [EMAIL PROTECTED]
Quantum Information           tel: 0113 343 3897
Physics & Astronomy          University of Leeds

Reply via email to