David Dawes wrote:
> The patch is necessary for building against freetype 2.1.7, because
> changes in header file names were hidden behind these macros.
BTW, what is this freetype-2.1.7 I keep reading about?
Isn't freetype hosted on SourceForge anymore? The latest version I see
there is 2.1.5. The freetype project moved somewhere else?
> My first question is, do you have a clean 4.3.99.901 tree?
Yup.
> The next question is, is '-I/usr/include -I/usr/include/freetype2' on
> the gcc command lines as it should be?
Yes it is.
> Can you send the actual build log extract for the failing part?
Sure:
#v+
rm -f ftfuncs.o unshared/ftfuncs.o
gcc -c -I/usr/include -I/usr/include/freetype2 -I. -I../../../include/fonts
-I../include -I../../../exports/include/X11 -I../../../programs/Xserver/include
-I../../../extras/freetype2/src/truetype -I../../../exports/include -I../../..
-I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXvExtension -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXFREE86_FT2 -march=pentium2 -Os -fomit-frame-pointer
-s -pipe -DNDEBUG -DG_DISABLE_ASSERT -s -z combreloc ftfuncs.c
ftfuncs.c:46:10: #include expects "FILENAME" or <FILENAME>
ftfuncs.c:47:10: #include expects "FILENAME" or <FILENAME>
[... CUT! Nearly 600 lines ...]
make: *** [ftfuncs.o] Błąd 1
#v-
> Also, check the depend stuff in the Makefile that gets created to
> see which "ft2build.h" file it thinks is getting used.
After "grep ft2build Makefile":
ftfuncs.o: ../include/fontutil.h /usr/include/ft2build.h
ftenc.o: ../include/fontutil.h ../include/fontenc.h /usr/include/ft2build.h
fttools.o: /usr/include/ft2build.h
If I replace the '#include <ft2build.h>' in ftfuncs.c with
#include "/usr/include/ft2build.h"
then it builds well. But if I leave the default '#include <ft2build.h>'
it fails.
But I think I know what's wrong. The gcc manual says:
"Directories named by -I are searched before the standard system include
directories."
So system directories, like /usr/include, have *lowest* priorities.
Anything "blessed" with -I will be checked first. It gets even worse:
"(...) If the directory dir is a standard system include directory, the
option (this means -I) is ignored"
So you can't do anything about it. The *only* way of solving this
would be rearranging xc's includes. If you want gcc to use
/usr/include/ft2build.h you need to make sure that gcc gets absolutely
no -I pointing to a directory with a second "ft2build.h" in it.
This isn't good, is it? It's not only freetype, it can probably happen
to expat, fontconfig etc.
Oh, and the troublemaking ft2build.h is, in this case, located in the
xc/lib/font/FreeType directory (-I .) Once you remove it, it all works.
And now I understand why. Well, this means that to ensure gcc3
compatibility the included external parts, like expat or freetype, would
need to be completely isolated from the build process. gcc should not be
allowed to learn about those includes unless they are really needed.
'cause if gcc finds them, it will use them instead of /usr/include.
> If you can figure out what the problem is and send a patch for it,
> that would be most welcome. It has to work with older versions of
> flex, as well as lex too.
Someone with flexperience would be needed...
On my config this does nicely:
--- xc/programs/twm/lex.c 2003-12-10 17:10:27.000000000 +0100
+++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.000000000 +0100
@@ -25,6 +25,8 @@
/* flex integer type definitions */
+int yy_prev_more_offset;
+
#ifndef FLEXINT_H
#define FLEXINT_H
But it's just a quick&dirty hack if someone (like me) is just interested
in getting a XFree86 release to compile.
I looked a bit at it, and it seems that flex, at least my flex-2.5.31,
uses a /usr/include/FlexLexer.h header. I guess this header needs to be
included in every flexed C source. However, greping twm for "FlexLexer"
yields no results.
But twm/lex.c already includes many, many definitions from FlexLexer.h
(some are still missing, like yy_prev_more_offset). I don't know the
history of flex - this /usr/include/FlexLexer.h is either something
really new, or someone embedded an older FlexLexer.h file in twm sources
long ago (which would explain why there are so many parts of FlexLexer.h
in it).
A good fix would be to kick redundand definitions out of twm/lex.c and
put a "#include <FlexLexer.h>" there instead. But I don't know if it
wouldn't break compatibility with older versions of flex or lex. I never
used flex, so I don't know how to solve this.
Argh, I don't like it. Two problems and I can't fix even a single one.
Oh well, maybe someone else will.
--
\hoppke
(Grzegorz "Grażyna" Niewęgłowski)
http://lubuska.zapto.org/~hoppke/
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
