On Wed, Dec 10, 2003 at 06:06:31PM +0100, Grzegorz Nieweglowski wrote: >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?
You can find it if you go to the freetype.org ftp site in France. I didn't see tarballs on the SourceForge site either. >> 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] Blad 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" Do the gcc people give a reason for not allowing a system directory to be "blessed" with -I? Maybe adding -nostdinc would help, but that would probably have unwanted side-effects. >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. There is no ft2build.h in the xc/lib/font/FreeType directory in 4.3.99.901 (it got moved to the only place that uses it: xc/lib/font/FreeType/module). That's why I asked if your 4.3.99.901 source was "clean" :-) I did see this problem myself before moving it. >> 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. On the FreeBSD 4.x system I'm using right now (which has flex 2.5.4), the only place on the system that FlexLexer.h is installed is /usr/include/g++/ ! >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. If there's a reliable way of knowing when to include <FlexLexer.h>, then we probably should include it. >Argh, I don't like it. Two problems and I can't fix even a single one. >Oh well, maybe someone else will. Portability can be a pain... David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
