Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what wrong would be because i dont know when it's What you consider wrong. :-) supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. The system one is only used for the module freetype backend build. In fact last night I committed a change that moves it (and some other locally modified headers) to the module directory so they can't be used by anything else. In my build tests with the patch, it only uses the local ft2build.h in that case. That's why if you're seeing something different I need some specific details in order to follow it up. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. So what's the point of having #define freetype2 if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. So because one out of the 4 or 5 things that reference freetype2 ignores the external one, we shouldn't allow the external one at all? If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David But why does xfree86
Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 08:33:41AM -0500, Ed Sweetman wrote: You wanted an example where things were getting mixed up. Here you go. In file included from /usr/local/include/freetype2/freetype/internal/ftobjs.h:31, from /usr/local/include/freetype2/freetype/internal/tttypes.h:26, from ftfuncs.c:53: /usr/local/include/freetype2/freetype/ftrender.h:24:21: freetype/ftmodule.h: No such file or directory Can you quote the full compile line, and the directory you're building in when this happens? There isn't enough context here. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Thu, Nov 20, 2003 at 09:25:29PM -0500, David Dawes wrote: On Thu, Nov 20, 2003 at 08:00:21PM -0500, Ed Sweetman wrote: David Dawes wrote: On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what wrong would be because i dont know when it's What you consider wrong. :-) supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. The system one is only used for the module freetype backend build. In fact last night I committed a change that moves it (and some other locally modified headers) to the module directory so they can't be used by anything else. In my build tests with the patch, it only uses the local ft2build.h in that case. That's why if you're seeing something different I need some specific details in order to follow it up. So what's the point of having #define freetype2 if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. So because one out of the 4 or 5 things that reference freetype2 ignores the external one, we shouldn't allow the external one at all? But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one. If you build a non-modular XFree86 server, then you get exactly that. Add '#define DoLoadableServer NO' to you host.def. You don't get that for the (default) modular XFree86 server because nobody has done the work necessary to build an XFree86 freetype backend module that can request that an external freetype library be loaded on demand. Remember the backend font modules are loaded optionally by the modular XFree86 server, so modules that use specific external interfaces should cause those interface to get loaded as required rather than requiring the core XFree86 binary to be linked against all conceivable external interfaces in advance. Until that work is done, the freetype backend module needs to contain its own complete copy of libfreetype. Feel free to do the work necessary to correct this obvious anomaly :-). The ttobjs.h issue needs to be addressed one way or another too, either by findind an equivalent public interface, or creating an equivalent public interface, so that this user-mode program can do what it needs to do without knowing more about the freetype internals than it has any right to :-) David Ok, so the module responsible for the actual rendering in Xfree86 is compiling against the local copy of freetype2 right? The reason why I Server side rendering, yes. Client side rendering, no. thought there was no reason to link to a local source tree because you're building it into a module, is that there are plenty of examples of programs with plugins that link to libraries like gtk and such without having local copies of such libraries. I take it this is very difficult to do with XFree86 since it was originally written in a non-modular form. We don't use dlopen() as our module loader (for semantic reasons, primarily). Nevertheless it's possible to do what is needed. It just needs to be done. Are there flags i can override in host.cf that will let me point xfree86 to a different source tree or can i just dump the system freetype2 source tree into xc/extras and do things that way? Otherwise i'll just No, because you'll also almost certainly need to modify lib/font/FreeType/module/Imakefile and some other files, which are likely tied fairly closely to the freetype version. Here's the latest error after your ftnew.diff OK, I hadn't checked the utilities that directly reference freetype. I'd only done the libraries. It uses quotes in the source file but doesn't appear to need to use the local copy of the source tree so i changed them to use the system copy headers. Of course this doesn't mean it'll be linked to the system library. :-/ it compiled though. It should be. Check for -L/path/to/your/installed/lib in the build log. The attached patch fixes these two utilities. I'll commit that too. My complete build against the external freetype installation hasn't finished yet (old slow machines, and all that). If there are more problems, I'll commit fixes for them too. forgot the patch... David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes Index: programs/mkfontscale/mkfontscale.c === RCS file: /home/x-cvs/xc/programs/mkfontscale/mkfontscale.c,v
[XFree86] freetype2 problems with cvs
Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes Index: lib/font/FreeType/Imakefile === RCS file: /home/x-cvs/xc/lib/font/FreeType/Imakefile,v retrieving revision 1.30 diff -u -r1.30 Imakefile --- lib/font/FreeType/Imakefile 5 Nov 2003 16:54:28 - 1.30 +++ lib/font/FreeType/Imakefile 20 Nov 2003 01:59:13 - @@ -10,10 +10,12 @@ DEFINES = ServerExtraDefines StrcasecmpDefines Freetype2BuildDefines \ -DXFREE86_FT2 +FT2SOURCEDIR = $(TOP)/extras/freetype2/src FT2INCS = -I$(FREETYPE2INCDIR) -I$(FREETYPE2INCDIR)/include -INCLUDES = -I. -I$(FONTINCSRC) -I../include -I$(XINCLUDESRC) \ - -I$(SERVERSRC)/include $(FT2INCS) -I$(INCLUDESRC) +INCLUDES = $(FT2INCS) -I. -I$(FONTINCSRC) -I../include -I$(XINCLUDESRC) \ + -I$(SERVERSRC)/include -I$(FT2SOURCEDIR)/truetype \ + -I$(INCLUDESRC) SRCS = xttcap.c ftfuncs.c ftenc.c fttools.c OBJS = xttcap.o ftfuncs.o ftenc.o fttools.o Index: lib/font/FreeType/ftenc.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/ftenc.c,v retrieving revision 1.24 diff -u -r1.24 ftenc.c --- lib/font/FreeType/ftenc.c 19 Oct 2003 18:53:49 - 1.24 +++ lib/font/FreeType/ftenc.c 20 Nov 2003 02:01:41 - @@ -35,12 +35,13 @@ #include fontmisc.h #include fontenc.h -#include freetype/freetype.h -#include freetype/ttnameid.h -#include freetype/tttables.h -#include freetype/t1tables.h -#include freetype/ftbdf.h -#include freetype/ftxf86.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_TABLES_H +#include FT_TYPE1_TABLES_H +#include FT_BDF_H +#include FT_XFREE86_H #include ft.h static int find_cmap(int, int, int, FT_Face, FT_CharMap *); Index: lib/font/FreeType/ftfuncs.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/ftfuncs.c,v retrieving revision 1.36 diff -u -r1.36 ftfuncs.c --- lib/font/FreeType/ftfuncs.c 2 Nov 2003 04:30:56 - 1.36 +++ lib/font/FreeType/ftfuncs.c 20 Nov 2003 02:01:49 - @@ -42,22 +42,23 @@ #include fntfilst.h #include fontutil.h #include FSproto.h -#include freetype/freetype.h -#include freetype/ftsizes.h -#include freetype/ttnameid.h -#include freetype/tttables.h -#include freetype/t1tables.h -#include freetype/ftxf86.h -#include freetype/ftbbox.h -#include freetype/internal/tttypes.h -#include extras/freetype2/src/truetype/ttobjs.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_SIZES_H +#include FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_TABLES_H +#include FT_TYPE1_TABLES_H +#include FT_XFREE86_H +#include FT_BBOX_H +#include FT_INTERNAL_TRUETYPE_TYPES_H +#include ttobjs.h /* * If you want to use FT_Outline_Get_CBox instead of * FT_Outline_Get_BBox, define here. */ /* #define USE_GET_CBOX */ #ifdef USE_GET_CBOX -#include freetype/ftoutln.h +#include FT_OUTLINE_H #endif #include fontenc.h Index: lib/font/FreeType/fttools.c === RCS file: /home/x-cvs/xc/lib/font/FreeType/fttools.c,v retrieving revision 1.6 diff -u -r1.6 fttools.c --- lib/font/FreeType/fttools.c 8 Jun 2003 15:41:13 - 1.6 +++ lib/font/FreeType/fttools.c 20 Nov 2003 02:01:55 - @@ -34,9 +34,10 @@ #endif #include font.h -#include freetype/freetype.h -#include freetype/ftsnames.h -#include freetype/ttnameid.h +#include ft2build.h +#include FT_FREETYPE_H +#include FT_SFNT_NAMES_H +#include FT_TRUETYPE_IDS_H #include ft.h #ifndef LSBFirst Index: lib/Xft/Xft.h
Re: [XFree86] freetype2 problems with cvs
David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include freetype/freetype.h and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include ft2build.h and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what wrong would be because i dont know when it's supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. So what's the point of having #define freetype2 if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
