Re: External FreeType build problem
On Wed, Dec 10, 2003 at 06:06:31PM +0100, Grzegorz Nieweglowski wrote: Someone with flexperience would be needed... On my config this does nicely: --- xc/programs/twm/lex.c 2003-12-10 17:10:27.0 +0100 +++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.0 +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 quickdirty hack if someone (like me) is just interested in getting a XFree86 release to compile. I just looked at this again. lex.c is generated by flex, so patching it won't work. Other versions of flex put the following in the generated lex.c: static int yy_prev_more_offset = 0; Even trying to work around it by adding something like the above to lex.l would break other builds. 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 They are there because flex puts them in the .c file it generates. It's a flex bug that it is not also putting in the definition for yy_prev_more_offset. I don't know if this has been fixed in a newer version of flex yet. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote: If you look through the 4.3.99.15-1.3.99.16 patch, you'll find the patch hunk that removes xc/lib/font/FreeType/ft2build.h. I don't know why it didn't happen for you. Well, you're right. After patching I'm left with some zero-length files. The patch documentation says, that patch should normally remove such empty files automatically, based on timestamp analysis. I guess that it's just that I've applied several patches that caused this trouble. The first patch got the right timestamps, but the next ones probably didn't. Mea culpa. At least now I know that I should use the '-E' option when patching to remove those empty files. I've generated a list of files from the current tarball and from my local version, compared them, and it appears that I have 87 redundant files. Well, at least now I know how to avoid that in the future - patch with -E. Many thanks for your patience :) -- \hoppke (Grzegorz Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote: Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include': gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -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 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c In file included from charproc.c:123: /usr/include/error.h:26: parse error This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm. One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour. The same holds for '-L/usr/lib' or '-L/usr/local/lib' in LDFLAGS. Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Thu, Dec 11, 2003 at 04:41:47PM +0100, Michael Lampe wrote: David Dawes wrote: Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include': gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -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 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c In file included from charproc.c:123: /usr/include/error.h:26: parse error This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm. One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour. Never /usr/local/include?? That's ridiculous. How are you deciding which ones are allowed and which are not? If you use these and have local headers that might conflict, then you must put -I. in explicitly first. Then there is no ambiguity. I'd say that's what needs to happen for xterm/Imakefile. If someone wants to try builds that currently rely on -I/usr/include and make sure they work correctly when they are removed, please do, and send reports of any problems. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote:
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of
this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef
-I../../exports/include -I/usr/include -I/usr/include/freetype2
-I../../exports/include/X11 -I../.. -I../../exports/include
-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 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I.
-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h
from programs/xterm.
One should never put an explicit '-I/usr/include' or
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of
strange behaviour.
Never /usr/local/include?? That's ridiculous. How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and
/usr/include are searched by default but in this order:
explicitly given includes first
/usr/local/include
/usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
/usr/lib/gcc-lib/i486-linux/2.95.3/include
/usr/include
In this order you normally get what you expect. For example, if you have
a more recent version of some library installed in /usr/local than in
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces
unexpected results, especially if you don't do it yourself but some
'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore
'-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason
something like this:
- from freetype-config -
if test $echo_cflags = yes ; then
cflags=-I${prefix}/include/freetype2
if test ${prefix}/include != /usr/include ; then ==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fi
if test $echo_libs = yes ; then
libs=-lfreetype -lz
if test ${exec_prefix}/lib != /usr/lib ; then ==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi
-
'-I/usr/local/include' and '-L/usr/local/lib' seem, on second thought,
not to be a problem.
If you use these and have local headers that might conflict,
I guess every unix has /usr/include/error.h
then
you must put -I. in explicitly first. Then there is no ambiguity.
I'd say that's what needs to happen for xterm/Imakefile.
Would obviously solve the xterm build problem. As would removing
'-I/usr/include'.
If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?
Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Thu, Dec 11, 2003 at 06:08:11PM +0100, Michael Lampe wrote:
David Dawes wrote:
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of
this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef
-I../../exports/include -I/usr/include -I/usr/include/freetype2
-I../../exports/include/X11 -I../.. -I../../exports/include
-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 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I.
-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h
from programs/xterm.
One should never put an explicit '-I/usr/include' or
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of
strange behaviour.
Never /usr/local/include?? That's ridiculous. How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and
/usr/include are searched by default but in this order:
explicitly given includes first
/usr/local/include
/usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
/usr/lib/gcc-lib/i486-linux/2.95.3/include
/usr/include
My gcc 2.95.3 on FreeBSD searches only /usr/include implicitly.
In this order you normally get what you expect. For example, if you have
a more recent version of some library installed in /usr/local than in
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces
unexpected results, especially if you don't do it yourself but some
'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore
'-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason
something like this:
- from freetype-config -
if test $echo_cflags = yes ; then
cflags=-I${prefix}/include/freetype2
if test ${prefix}/include != /usr/include ; then ==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fi
if test $echo_libs = yes ; then
libs=-lfreetype -lz
if test ${exec_prefix}/lib != /usr/lib ; then ==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi
-
We already do that for the freetype library. I'm not sure why we
didn't for the includes -- probably to try to make sure that the
correct freetype headers get included. Anyway, I'm testing a patch
that does this for freetype includes and installs our ft2build.h in a
better place.
Would obviously solve the xterm build problem. As would removing
'-I/usr/include'.
Not if there happened to be an error.h in one of the other -I
paths used in its build.
If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?
That's not the point. What needs to be tested is that a header
elsewhere (under one of the other -I paths) doesn't get erroneously
included instead of the one under /usr/include.
As I said, those interested in making sure that this works correctly
should test it and post the results here.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
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] Bd 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.0 +0100 +++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.0 +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 quickdirty 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 Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED]
Re: External FreeType build problem
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? For some reason they've put 2.1.7 on their ftp site, but not on the sourceforge download page. You can find it at ftp://ftp.freetype.org/freetype/freetype2/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
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.0 +0100 +++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.0 +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 quickdirty 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
Re: External FreeType build problem
David Dawes nawypisowywa(a): 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. Oh, thanks! But that's strange, SourceForge doesn't know about the newest release, even official freetype mirrors are very out of date... it's like they're hiding it from the public... (...) 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? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. 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. But... but my tree is clean. It just isn't a pure 4.3.99.901 tarball, because some time ago I've downloaded 4.3.99.14 and then gradually patched it up. But all I did was unpack the archive, apply the newest patch and repack it. I tried not to break anything, really :) I know that not all changes can be registered by diff (and reproduced by patch) but I expected it only to affect non-textual files, like some images or maybe binary fonts. Diffpatch are pretty reliable when it comes to creating/removing text files, at least that's my impression. But I guess you'd need to use the '-N' diff option to get that behavior (at least with GNU diff), and the official patches don't do that, they only use -u. Is the -N something available only with some special versions of diff? Or would it be possible to generate future patches with -uN ? If there's a reliable way of knowing when to include FlexLexer.h, then we probably should include it. I've just noticed that my FlexLexer.h requires iostream and maybe some more C++ parts. Maybe that was the reason for merging parts of it into twm - to avoid the dependencies on a C++ compiler? If you would include this header, you would probably need something like g++ to compile twm. Not very nice, is it now. So maybe it would be easier to just play along and keep it the way it is now... just patch twm up a bit so that it compiles with older and newer flex releases... Would my, ekhm, patch cause trouble with older flex versions? -- \hoppke (Grzegorz Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
External FreeType build problem
I have trouble with a fix that appeared somewhere between 4.3.99.15 and 4.3.99.16 (and is still present in 4.3.99.901). I've browsed the changelogs and there was something that was supposed to help XFree86 build with external freetype libraries, but... well, on my config it did exactly the opposite, I think. Making World with #define HasFreetype2 YES #define BuildFreetype2Library NO in my xc/config/cf/host.def fails in xc/lib/font/FreeType/ on ftfuncs.c. Seems as those freetype include definitions used in there newer got declared and gcc complains #include expects FILENAME or FILENAME. In previous releases, up to (and including) 4.3.99.14 using #define HasFreetype2 YES #define BuildFreetype2Library NO allowed me to compile XFree86 using a system-wide installed freetype2-2.1.5. But it's no longer possible. So... am I missing something, or is it a bug? -- \hoppke http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Mon, Dec 08, 2003 at 11:44:40PM +0100, Grzegorz Nieweglowski wrote: I have trouble with a fix that appeared somewhere between 4.3.99.15 and 4.3.99.16 (and is still present in 4.3.99.901). I've browsed the changelogs and there was something that was supposed to help XFree86 build with external freetype libraries, but... well, on my config it did exactly the opposite, I think. Making World with #define HasFreetype2 YES #define BuildFreetype2Library NO in my xc/config/cf/host.def fails in xc/lib/font/FreeType/ on ftfuncs.c. Seems as those freetype include definitions used in there newer got declared and gcc complains #include expects FILENAME or FILENAME. I had the same problem and reverted one line of the change by using the following patch. --- lib/font/FreeType/ftfuncs.c.old 2003-11-23 23:59:12.518624452 + +++ lib/font/FreeType/ftfuncs.c 2003-11-24 00:01:16.660583100 + @@ -51,7 +51,7 @@ #include FT_XFREE86_H #include FT_BBOX_H #include FT_INTERNAL_TRUETYPE_TYPES_H -#include ttobjs.h +#include extras/freetype2/src/truetype/ttobjs.h /* * If you want to use FT_Outline_Get_CBox instead of * FT_Outline_Get_BBox, define here. I'm not sure if this a XFree86 bug or if just the include file is missing in the freetype2-devel package. Stefan Public Key available Stefan Dirsch (Res. Dev.) SuSE Linux AG Tel: 0911-740530 Deutschherrnstr. 15-19 FAX: +49 911 741 77 55D-90429 Nürnberg http://www.suse.deGermany ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
Stefan Dirsch wrote: I had the same problem and reverted one line of the change by using the following patch. (...) Thanks, but it didn't work for me. However, I managed to solve it on my box by adding a #include freetype/config/ftheader.h to all troublemaking files. I looked at the 4.3.99.15-4.3.99.16.diff.bz2 patch. The idea behind that patch was correct, removing clutter and really trying to push freetype references out of the local tree, replacing '#include foo' with '#include FT_FOO'. But I did noticed something else: there really shouldn't be ANY need for me to add my own include: See, the patch always added a #include ft2build.h And my /usr/include/ft2build.h looks like this: #ifndef __FT2_BUILD_UNIX_H__ #define __FT2_BUILD_UNIX_H__ #include freetype/config/ftheader.h #endif /* __FT2_BUILD_UNIX_H__ */ So it should automatically include the file freetype/config/ftheader.h. Unless __FT2_BUILD_UNIX_H__ was already defined. *Or* the compiler directive '#include ft2build.h' wasn't picking up the /usr/include/ft2build.h file... So I checked the access time on /usr/include/ft2build.h... ...and I was right. Nothing had accessed it. My conclusion: I'm using gcc-3.2.3. And that is probably the key to the whole mess. Newer releases of gcc treat the '-I' command line options a bit differently now, the include directories are searched in a different order than they would have been searched with earlier versions of gcc. And this bad, bad thing that happens when you try to use an external freetype is that gcc (at least my gcc) picks some includes from /usr/include/freetype2, and some from xc/extras/freetype2. I found that I really don't even need any patches. All I have to do is remove all ft2build.h files from the xc tree and it will build nicely. So it is obviously something related to the order in which my gcc picks up header files. Because no-one else reported this, I guess it's a gcc-version-incompatibility thing. But that's the way it goes with newer tools, for example twm won't compile with my flex-2.5.31. Compilation fails with stdout: In function `yylex': stdout:837: error: `yy_prev_more_offset' undeclared (first use in this function) stdout:837: error: (Each undeclared identifier is reported only once stdout:837: error: for each function it appears in.) not that I care, I don't need twm, but I think that xfree86 developers really could update their devel tools, some of us users are maybe using more up-to-date tools and XFree86 just won't compile for us :/ -- \hoppke ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Tue, Dec 09, 2003 at 11:02:32AM +0100, Stefan Dirsch wrote: On Mon, Dec 08, 2003 at 11:44:40PM +0100, Grzegorz Nieweglowski wrote: I have trouble with a fix that appeared somewhere between 4.3.99.15 and 4.3.99.16 (and is still present in 4.3.99.901). I've browsed the changelogs and there was something that was supposed to help XFree86 build with external freetype libraries, but... well, on my config it did exactly the opposite, I think. Making World with #define HasFreetype2 YES #define BuildFreetype2Library NO in my xc/config/cf/host.def fails in xc/lib/font/FreeType/ on ftfuncs.c. Seems as those freetype include definitions used in there newer got declared and gcc complains #include expects FILENAME or FILENAME. I had the same problem and reverted one line of the change by using the following patch. --- lib/font/FreeType/ftfuncs.c.old 2003-11-23 23:59:12.518624452 + +++ lib/font/FreeType/ftfuncs.c 2003-11-24 00:01:16.660583100 + @@ -51,7 +51,7 @@ #include FT_XFREE86_H #include FT_BBOX_H #include FT_INTERNAL_TRUETYPE_TYPES_H -#include ttobjs.h +#include extras/freetype2/src/truetype/ttobjs.h /* * If you want to use FT_Outline_Get_CBox instead of * FT_Outline_Get_BBox, define here. lib/font/FreeType/Imakefile has -I$(FT2SOURCEDIR)/truetype in INCLUDES, and FT2SOURCEDIR = $(TOP)/extras/freetype2/src, so ttobjs.h should be found there. (It is for me.) David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Tue, Dec 09, 2003 at 07:26:06PM +0100, Grzegorz Nieweglowski wrote: Stefan Dirsch wrote: I had the same problem and reverted one line of the change by using the following patch. (...) Thanks, but it didn't work for me. However, I managed to solve it on my box by adding a #include freetype/config/ftheader.h to all troublemaking files. I looked at the 4.3.99.15-4.3.99.16.diff.bz2 patch. The idea behind that patch was correct, removing clutter and really trying to push freetype references out of the local tree, replacing '#include foo' with '#include FT_FOO'. But I did noticed something else: there really shouldn't be ANY need for me to add my own include: See, the patch always added a The patch is necessary for building against freetype 2.1.7, because changes in header file names were hidden behind these macros. #include ft2build.h And my /usr/include/ft2build.h looks like this: #ifndef __FT2_BUILD_UNIX_H__ #define __FT2_BUILD_UNIX_H__ #include freetype/config/ftheader.h #endif /* __FT2_BUILD_UNIX_H__ */ So it should automatically include the file freetype/config/ftheader.h. Unless __FT2_BUILD_UNIX_H__ was already defined. *Or* the compiler directive '#include ft2build.h' wasn't picking up the /usr/include/ft2build.h file... So I checked the access time on /usr/include/ft2build.h... ...and I was right. Nothing had accessed it. My conclusion: I'm using gcc-3.2.3. And that is probably the key to the whole mess. Newer releases of gcc treat the '-I' command line options a bit differently now, the include directories are searched in a different order than they would have been searched with earlier versions of gcc. And this bad, bad thing that happens when you try to use an external freetype is that gcc (at least my gcc) picks some includes from /usr/include/freetype2, and some from xc/extras/freetype2. My first question is, do you have a clean 4.3.99.901 tree? If you extracted the source tarball on top of an older one, some files that have since been deleted will still be there and might be affecting your build. The next question is, is '-I/usr/include -I/usr/include/freetype2' on the gcc command lines as it should be? Can you send the actual build log extract for the failing part? Also, check the depend stuff in the Makefile that gets created to see which ft2build.h file it thinks is getting used. I found that I really don't even need any patches. All I have to do is remove all ft2build.h files from the xc tree and it will build nicely. So it is obviously something related to the order in which my gcc picks up header files. Because no-one else reported this, I guess it's a gcc-version-incompatibility thing. But that's the way it goes with newer tools, for example twm won't compile with my flex-2.5.31. Compilation fails with stdout: In function `yylex': stdout:837: error: `yy_prev_more_offset' undeclared (first use in this function) stdout:837: error: (Each undeclared identifier is reported only once stdout:837: error: for each function it appears in.) not that I care, I don't need twm, but I think that xfree86 developers really could update their devel tools, some of us users are maybe using more up-to-date tools and XFree86 just won't compile for us :/ 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. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
