Closed Bug 234035 Opened 21 years ago Closed 13 years ago

freetype2 2.1.8 compile error: FTC_Image_Cache_* APIs are not available any more

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.5alpha

People

(Reporter: jshin1987, Assigned: jshin1987)

References

Details

(Keywords: intl)

Attachments

(5 files, 6 obsolete files)

trace of mozilla with patch but crashing on printing
20.05 KB, text/plain
Details
patch for gtk2+xft only
6.74 KB, patch
jshin1987
: review+
bryner
: superreview+
Details | Diff | Splinter Review
patch part 2 (for builds with '--enable-freetype2' )
32.48 KB, patch
Details | Diff | Splinter Review
profiling result (with and without patch)
282.44 KB, application/x-gzip
Details
Freetype 2.1.8 patch for mozilla 1.7.7
17.14 KB, patch
Details | Diff | Splinter Review
FTC_Image_Cache_* APIs are not available any more in recent freetype2 library. They're replaced by FTC_ImageCache* APIs, but their calling sequences are different. I wrote to the freetype list how long ago new APIs were introduced to determine whether or not check it at a run-time.
Summary: freetype2 : FTC_Image_Cache_* APIs are not available any more → freetype2 : FTC_Image_Cache_* APIs are not available any more
I can't compile Mozilla, presumably because of this bug and because my version of freetype is too recent (9.6.3). I tried substituting version 2.0.9 of freetype, and that eliminated complaints about a missing FTC_Image_Cache, but led to other compilation and linking errors -- just too much for me to deal with. So I hope someone can fix this.
I also noticed this problem and when I changed all FTC_Image_Cache to FTC_ImageCache the build crossed that stage and again failed at FTC_Image_Desc for same reason . Looks like FTC_Image_Desc is also deprecated.
Please see this URL for about comments on Freetype 2.1.8 http://mail.gnome.org/archives/epiphany-list/2004-April/msg00057.html When I tried compiling Mozilla with freetype 2.1.7 it went fine. So probably we can wait on this bug for the next release of freetype?
Severity: normal → major
Summary: freetype2 : FTC_Image_Cache_* APIs are not available any more → freetype2 2.1.8 compile error: FTC_Image_Cache_* APIs are not available any more
*** Bug 241290 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > There are patches in NetBSD package. > See cvsweb or commit messages for detail. > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/mozilla/patches/ > http://mail-index.netbsd.org/pkgsrc-changes/2004/04/29/0025.html I had the same problem compiling mozilla with freetype 2.1.8. Those patches solved the problem. I am typing this up in my patched mozilla right now. There appear to be no ill effects from the patches. Will they be integrated into the main mozilla tree anytime soon, because as distributions begin upgrading their freetype libraries more and more people will have this problem compiling mozilla.
Attached patch FreeType-2.1.9 patch (obsolete) — — Splinter Review
Attached patch contains (as its name implies) all modifications to FreeType and Mozilla CVS source trees du jour.
Flags: blocking1.8a2?
Flags: blocking1.7?
Flags: blocking1.7?
Has this patch been applied to the source tree yet? If not, any idea when?
Thanks for the patch. This is a thorny issue. mozilla.org build machines still have old freetype library and so do most developers' machines. Therefore, the patch as it stands cannot be committed. We can add a lot of #ifdef'd code, but I'm not sure how to handle this problem. Actually, it's a bit more complicated than that because we have to deal with both compile-time and run-time dependency. I guess we have to worry less about the latter than the former because new APIs appear to have been introduced quite a long time ago.
0 prob. Wait & C until this issue becomes real issue.
Comment on attachment 149334 [details] [diff] [review] FreeType-2.1.9 patch Thanks for the patch. I realized that new APIs have been around for over a year (if not a lot longer) and most Linux distributions have a version of freetype with them (including RH9, FC1, SuSE 9.x, Mandrake) although legacy APIs (currently used by Mozilla) were removed only recently. So, this patch should be rather safe. >- void imageCacheLookup(in FTC_Image_Cache cache, in FTC_Image_Desc_p desc, >+ void imageCacheLookup(in FTC_ImageCache cache, in FTC_ImageType_p desc, Perhaps, 's/desc/type/' would be better. >Index: gfx/src/freetype/nsFreeType.cpp >-nsFreeType2::ImageCacheLookup(FTC_Image_Cache cache, FTC_Image_Desc *desc, >+nsFreeType2::ImageCacheLookup(FTC_ImageCache cache, FTC_ImageType *desc, > FT_UInt glyphID, FT_Glyph *glyph) same here. >Index: gfx/src/ps/nsFontMetricsPS.cpp >- mImageDesc.font.face_id = (void*)mEntry; >- mImageDesc.font.pix_width = mPixelSize; >- mImageDesc.font.pix_height = mPixelSize; >- mImageDesc.image_type = 0; >+ mImageDesc->face_id = (FTC_FaceID)&mEntry; >+ mImageDesc->width = mPixelSize; >+ mImageDesc->height = mPixelSize; >+ mImageDesc->flags = 0; same here: s/mImageDesc/mImageType/ >Index: gfx/src/ps/nsFontMetricsPS.h >- FTC_Image_Desc mImageDesc; >+ FTC_ImageType mImageDesc; ditto and a couple of other places. >- if (nsFreeType2::gFreeType2Autohinted) >- mImageDesc.image_type |= ftc_image_flag_autohinted; >- >- if (nsFreeType2::gFreeType2Unhinted) >- mImageDesc.image_type |= ftc_image_flag_unhinted; Shouldn't we 'OR' |mImageType->flag| with FT_LOAD_FORCE_AUTOHINT and FT_LOAD_NO_HINTING, respectively? >- > PRUint32 num_embedded_bitmaps, i; > PRInt32* embedded_bitmapheights; > mFaceID->GetEmbeddedBitmapHeights(&num_embedded_bitmaps, >@@ -218,7 +211,6 @@ nsFreeTypeFont::nsFreeTypeFont(nsITrueTy > if (embedded_bitmapheights[i] == aPixelSize) { > embedded_bimap = PR_TRUE; > // unhinted must be set for embedded bitmaps to be used >- mImageDesc.image_type |= ftc_image_flag_unhinted; > break; > } > } same here.
Attachment #149334 - Flags: review+
(In reply to comment #11) > (From update of attachment 149334 [details] [diff] [review]) > Thanks for the patch. I realized that new APIs have been around for over a > year (if not a lot longer) and most Linux distributions have a version of > freetype with them (including RH9, FC1, SuSE 9.x, Mandrake) although legacy > APIs (currently used by Mozilla) were removed only recently. So, this patch > should be rather safe. As far as FTC_ImageCache* APIs are concerend, the above is the case. However, the signature of FTC_ImageType (FTC_ImageTypeRec_) has changed recently. For instance, in freetype 2.1.5, it's defined as typedef struct FTC_ImageTypeRec_ { FTC_FontRec font; FT_Int32 flags; } FTC_ImageTypeRec; while in freetype 2.1.9, it's defined as typedef struct FTC_ImageTypeRec_ { FTC_FaceID face_id; FT_Int width; FT_Int height; FT_Int32 flags; } FTC_ImageTypeRec; This difference is a real headache....
Status: NEW → ASSIGNED
Flags: blocking1.8a2? → blocking1.8a2-
*** Bug 252218 has been marked as a duplicate of this bug. ***
freetype 2.1.9 API http://freetype.sourceforge.net/freetype2/docs/reference/ft2-cache_subsystem.html#FTC_ImageCache_Lookup FT_EXPORT( FT_Error ) FTC_ImageCache_Lookup( FTC_ImageCache cache, FTC_ImageType type, FT_UInt gindex, FT_Glyph *aglyph, FTC_Node *anode ); different with the patch.
The patch works for me with freetype 2.1.9. I had to fix Xft.h too but that's not mozilla's fault.
Attachment #149334 - Flags: superreview?(blizzard)
Comment on attachment 149334 [details] [diff] [review] FreeType-2.1.9 patch this cannot go in as it is. The way FT2 library has changed over the time makes it rather hard to come up with a patch that will build and run across versions of FT2.
Attachment #149334 - Flags: superreview?(blizzard)
Attachment #149334 - Flags: review+
I've applied the patch and it works well for normal builds but I'm having problems with an SVG-enabled build. It fails at line 443 in /mozilla/layout/svg/renderer/src/libart/nsSVGLibartGlyphMetricsFT.cpp with the error nsSVGLibartGlyphMetricsFT.cpp:443: error: `FTC_Image_Desc' undeclared (first use this function) I've tried hacking at it with gedit but I know nothing about c++ and I've only got the patch for guidance so I've only succeeded in changing the error
I had this problem too -- I had to disable SVG. And although the patch worked on Firefox, it caused certain crashers in Mozilla (mail). So in the end I simply downgraded my Freetype to 2.1.7 and make do with hoping that the Freetype interface gets unbroken, as this never should have happened anyway during a stable release series...
*** Bug 247430 has been marked as a duplicate of this bug. ***
*** Bug 255259 has been marked as a duplicate of this bug. ***
The dependency on Freetype 2.1.7 should be mentioned in the build instructions at http://www.mozilla.org/build/unix-details.html, with warnings that newer versions will not work, similar to libIDL.
That's a good idea. I wrote to leaf (the author of the document) to add such a warning.
Those build instructions http://www.mozilla.org/build/unix-details.html seem to be a bit out of date. They say libIDL-0.8.x won't work but I have no problem building with libIDL-0.8.3. Same thing with autoconf - it says autoconf-2.5x won't work but autoconf-2.59 doesn't give me any trouble
If freetype > 2.1.7 doesn't work, we should have a configure check to stop the build. People generally don't read the build instructions. libIDL-0.8.x only works if you're building against gtk2. Are you actually using autoconf-2.59 to regenerate mozilla/configure and running a full build or do you just have it installed? 2.59 still fails to regenerate configure here.
libIDL-0.8.3 works for gtk1 if you make a symbolic link called /usr/bin/libIDL-config pointing at /usr/bin/libIDL-config-2 . I think you're probably right about autoconf, I either do ./configure, make or make -f client make so maybe autoconf isn't used at all. I don't think a check in the configure script is the answer as the patch http://bugzilla.mozilla.org/attachment.cgi?id=149334&action=view works and a configure check would need to be removed by the patch. The Mozilla code needs to be updated to live with the current tools people are using. It shouldn't stay fixed in the past depending on legacy versions. Gnome and everything else on my computer built cleanly with freetype-2.1.9. Nothing else needed patching. The Mozilla code is the odd one out.
(In reply to comment #25) > be updated to live with the current tools people are using. It shouldn't stay > fixed in the past depending on legacy versions. Not everyone is actively updating their libraries to the bleeding-edge version. FC1 has FT 2.1.3 and FC2 has FT 2.1.7. I guess other major distributions haven't updated their FT2 to 2.1.8 or newer, either. > Gnome and everything else on my > computer built cleanly with freetype-2.1.9. That doesn't say much. Most, if not all, of Gnome don't directly rely on freetype. Pango takes a special measure to protect itself against the whim of FT2 APIs (basically, it's statically linked against FT2) > Nothing else needed patching. The > Mozilla code is the odd one out. Mozilla can be made to compile both with 2.1.7 or earlier and 2.1.8 or later with #ifdef's. However, that doesn't solve the problem of Mozilla compiled with one version of FT2 not being runnable where the other version of FT2 is installed. If there's a way for that, let me know.
FC3 will most likely have FT2 > 2.1.8 as Rawhide now contains 2.1.9.
I want some feedback as to how to proceed. We have three options: 1) keep our code as it is now and block building with FT 2.1.8 or later at the configuration time : new Linux distribution users would suffer. Even if we do this, this bug should be kept open because eventually more and more people will have 2.1.8 or later. 2) check the FT2 version at the configuration time and add #ifdef'd blocks so that Mozilla will build with both FT <= 2.1.7 and FT >= 2.1.8. However, a binary built with FT <= 2.1.7 won't run where FT >= 2.1.8 is installed and vice versa. For instance, mozilla.org's tinder boxes have FT <= 2.1.7 so that nightlies built there won't be run on upcoming FC3 with FT 2.1.9. 3) In addition to what we do at 2), add some wrappers over FT2 APIs so that a binary built with FT <= 2.1.7 can be run where FT >= 2.1.8 is available and vice versa (if it can be done with not much hassle) 4) statically build with libfreetype2 ...... What would you say?
I've started mozilla building with static FT 2.1.7. Is it's licence unrestrictive enough to include the source tree into the mozilla source (just like XFree86 does) ? Ideally freetype.org developers shouldn't have changed their API without bumping up the major version of the library. This is what library versioning is for.
I see in-tree FT2 and static linking to be the only solution, personally. :( The mostly-BSD-ish license looks amenable to this (but IANAL): http://www.freetype.org/license.html
Oh, of course there is potentially another option: don't use FT2's glyph cache at all (which in fairness they've always described as 'experimental' AFAICS). Moz's codebase has its own tried-and-tested cache classes out of the wazoo I think. What's more, assuming that we end up shunting the glyph pixel data off to belong to the X server (or other rendering device) eventually and that the X server's capacity for glyphs is as large as we might want to cache, there's probably no reason to keep the glyph pixel data around at the library or application level at all, so we can save memory.
Another possible solution to the FreeType version madness would be compilation with the latest release and runtime detection like this 1: FT_Error ftError; FT_Library ftLibrary; FT_Int ftMajor, ftMinor, ftPatch; ftError = FT_Init_FreeType(&ftLibrary); FT_Library_Version(ftLibrary, &ftMajor, &ftMinor, &ftPatch);
*** Bug 258829 has been marked as a duplicate of this bug. ***
Why don't we just stick with stable apis? Do we really need the caching apis?
current checkouts still don't work!! though patch seems to be applied.
Did you apply the patch in comment #56 of this bug http://bugzilla.mozilla.org/show_bug.cgi?id=190031#c56 and add this to your mozconfig ac_add_options --disable-freetype2
yes. tried a current checkout with and without patch. and i always use --disable-freetype2. i don't use any .mozconfig file.
The patch attached as FreeType-2.1.9.patch solved the compile issues I had with mozilla-1.7.3 on slackware 8.0, gcc-3.4.2, glibc-2.3.2 and freetype-2.1.9
It seems that the current trunk source includes additional freetype2-related codes. I had compile errors in nsFontMetricsPS.cpp, and manually modified it by following the existing patch, but I couldn't get rid of this error. /usr/X11R6/include/freetype2/freetype/ftcache.h: in member function `virtual nscoord nsFontPSXft::GetWidth(const PRUnichar*, unsigned int)': /usr/X11R6/include/freetype2/freetype/ftcache.h:661: error: too few arguments to function `FT_Error FTC_ImageCache_Lookup(FTC_ImageCacheRec_*, FTC_ImageTypeRec_*, unsigned int, FT_GlyphRec_**, FTC_NodeRec_**)' nsFontMetricsPS.cpp:1155: error: at this point in file Maybe this error is related to the things written in comment #14, but it is too much for me because I have no experience in programming. Could someone solve this problem?
Here is the patch I used to build recent trunk Firefox. However, now I got segfault every time I print preview in nsFontPSXft::Init().
you can refer to the patch bug http://bugzilla.mozilla.org/show_bug.cgi?id=190031#c56 FTC_Manager_Lookup_Size() need be devided into two steps in FT2.1.8: 1. first do FTC_Manager_LookupSize() 2. then do FTC_Manager_LookupFace(). After do that, mozilla will not crash now.
Thanks, Ervin. Print Preview works fine now.
I tried to patch firefox 1.0pr sources and current cvs with patches available here and also with those from http://bugzilla.mozilla.org/show_bug.cgi?id=190031 Yup, at least it compiles. But it seems that selecting Helvetica (or some other fonts) as standard serif font and exiting from firefox preferences is still enough to make it crash with the following: /home/james/files/firefox/run-mozilla.sh: line 159: 4665 Segmentation fault "$prog" ${1+"$@"}
Attachment #159821 - Attachment is obsolete: true
Here is updated patch I used to build my trunk Firefox. There is no problem so far. I am sure about 1.0PR, but if it applied okay, should work as well.
I have a mozilla built from CVS on Oct 2. I applied the patch from attachment 159281 [details] [diff] [review]. I am using freetype 2.1.9 and enabled gtk2 and xft. The patch applied fine and mozilla built without problems. Whenver I try to click OK after changing a font in edit -> preferences or whenever I visit certain webpages that I frequent, mozilla segfaults with an error of "$prog" ${1+"$@"}. Any ideas or what else should I submit to help track this down?
Oops, I meant 159844 in the previous comment.
*** Bug 263199 has been marked as a duplicate of this bug. ***
patch works but printing to a file creates a coredump!
Any progress on this guys ? Jungshik what's you decision on this ?
(In reply to comment #49) > Which patch? Printing to a file works for me with a build patched with both > https://bugzilla.mozilla.org/attachment.cgi?id=149334&action=view and > https://bugzilla.mozilla.org/attachment.cgi?id=156865&action=view second one with mozilla 1.8a4 release :-(
This patch https://bugzilla.mozilla.org/attachment.cgi?id=159844&action=view solved my compilation problem in 1.8alpha4 please remove the other patches as they are causing confusion and are out dated
to comment #52: This patch crashes my mozilla when I try to print :-(
I'm afraid that you are right. After recompiling I got seg faults when trying to print. This happens all the time. I've created a trace and attached that to the bug report.
After applying the patch as in comment 52 mozilla now crashes while trying to print. A trace has been attached I hope this helps on the debugging of the problem
I'm trying to implement what's suggested in comment #31 and comment #34. That is, get rid of all the dependence on FT2 cache APIs. For the screen rendering, it shouldn't make much difference in perf. because X server itself has caching mechanism as suggested in comment #31. For printing, perf. shouldn't be much of a concern in the first place.
This should fix the problem for Xft + gtk2 (--enable-xft, --disable-freetype2) that uses FT2 APIs only for printing. I'll extend this to fix the problem for a build with freetype2 enabled.
In the previous patch, I forgot to get rid of a few lines of FT-cache related member variables in nsFontMetricsPS.h
Attachment #162199 - Attachment is obsolete: true
Comment on attachment 162207 [details] [diff] [review] fix v2 for Xft+gtk2 that should work for any version of FT2 >@@ -337,18 +337,16 @@ public: > #endif > > nsXftEntry *mEntry; > FT_Face getFTFace(); > > protected: > PRUint16 mPixelSize; >- FTC_Image_Desc mImageDesc; > FT_Library mFreeTypeLibrary; > FTC_Manager mFTCacheManager; >- FTC_Image_Cache mImageCache; 'FTC_Manager mFTCacheManager' should be removed as well.
With or without freetype2 enabled, printing works fine. However, with freetype enabled, the screen rendering with FT2 doesn't work. For gtk2(+xft), this doesn't matter because freetype is not used for the screen rendering.
Attachment #162207 - Attachment is obsolete: true
I've tested the patch in comment 58 and it works fine at first sight. Mozilla also stopped crashing when doing any print related stuff. I'll test the newer patch tomorrow.
I'm gonna fix this bug in two steps (and maybe one more step in which I'll add caching if necessary). In the first step, I'll just fix gtk2+xft build which is the default build option for firefox. It's also used by most Linux distribution builders. This patch also includes the fix for gtk2 + xft. In the second step, I'll fix x11core + freetype. Attachment 162239 [details] [diff] is my first shot at that, but the screen rendering doesn't work while the printing works fine. re: comment #61 Thanks for testing. You don't need to test attachment 162239 [details] [diff] [review] because you must be building with gtk2=xft (otherwise, my previous patch wouldn't have changed anything). This patch is almost identical to attachment 162207 [details] [diff] [review]. Nonetheless, it'd be nice if you could test this with FT 2.1.8 or later.
Attachment #149334 - Attachment is obsolete: true
Attachment #159844 - Attachment is obsolete: true
Attachment #162239 - Attachment is obsolete: true
Comment on attachment 162261 [details] [diff] [review] patch for gtk2+xft only asking for review.
Attachment #162261 - Flags: review?(Ervin.Yan)
I tested version 3 of the patch. It's working fine with Freetype-2.1.9 here on linux from scratch. I also installed Slackware 10 so I could test it building against freetype-2.1.7 and it works fine there too.
Now this works fine with my build with 'enable-freetype2' and FT 2.1.7 or earlier, but it should work just fine with FT 2.1.8 or later because it doesn't use any FT2 caching APIs.
Comment on attachment 162272 [details] [diff] [review] patch part 2 (for builds with '--enable-freetype2' ) FYI, I could apply this patch to 1.7/1.0 aviary branch as well. I haven't tried to build a branch build with this patch (I need to enable freetype2, but my branch build is configured for gtk2+xft)
(In reply to comment #62) > I'm gonna fix this bug in two steps (and maybe one more step in which I'll add > caching if necessary). The last step (adding our own glyph caching) seems to be necessary. I've been testing it with a debug build (with zillions of lines of debug output passing by in my xterm) and the debug output kinda of hides the perf. degradation caused by my patch (that does not use FT2 glyph caching any more). When I made an optimized build, the perf. difference became too obvious to miss. It may not be so conspicuous when printing non-CJK pages, though. Even for CJK pages, it's still 'tolerable' (it's only for printing as far as the patch for gfx2+xft is concerned). It's rather simple to add our own glyph caching, but I'd rather get attachment 162261 [details] [diff] [review] checked in first before adding it (which I expect to be able to work on next weekend)
I'm currently testing patch 8&9 combined and all works fine so far. I've tried to compile gnome with xft and freetype2 but the ./configure script doesn't allow for this. So I'm running with xft only for now.
confirming. both patches works ok on Slack current (10+)
I'm not all that concerned about printing performance, as long as we're not talking minutes. I think that working slowly is better than not working faster.
Comment on attachment 162261 [details] [diff] [review] patch for gtk2+xft only asking for r/sr. I'm not concerned about the printing perf. much either. I planned to work on it this weekend, but I'm afraid I can't. I'll next week when I'll also try to fix SVG.
Attachment #162261 - Flags: superreview?(dbaron)
Attachment #162261 - Flags: review?(blizzard)
Attachment #162261 - Flags: review?(Ervin.Yan)
current firefox checkout, patch 162261: CC -o nsPostScriptObj.o -c -DOSTYPE=\"IRIX6\" -DOSARCH=\"IRIX\" -DHAVE_DEPENDENT_LIBS -I../.. -I../../../../mozilla/gfx/src/ps/.. -I../../../../mozilla/gfx/src/ps/../shared -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/widget -I../../../dist/include/pref -I../../../dist/include/caps -I../../../dist/include/locale -I../../../dist/include/uconv -I../../../dist/include/view -I../../../dist/include/necko -I../../../dist/include/imglib2 -I../../../dist/include/unicharutil -I../../../dist/include/gfx -I../../../dist/include -I/mnt/3/moz/obj2/dist/include/nspr -I. -I/usr/nekoware/include -I/usr/nekoware/include/freetype2 -KPIC -I/usr/local/include -I/usr/nekoware/include -LANG:exceptions=OFF -woff 3262 -G 4 -n32 -DNDEBUG -DTRIMMED -O3 -I/usr/nekoware/include/glib-2.0 -I/usr/nekoware/lib/glib-2.0/include -I/usr/nekoware/include/pango-1.0 -I/usr/nekoware/include -I/usr/nekoware/include/freetype2 -I/usr/nekoware/include/gtk-2.0 -I/usr/nekoware/include/atk-1.0 -I/usr/nekoware/lib/gtk-2.0/include -I/usr/local/include -I/usr/nekoware/include -DMOZILLA_VERSION=\"1.8a5\" -DIRIX=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_SIGINFO_T=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_CDEFS_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DFUNCPROTO=15 -DHAVE_XSHM=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_STAT64=1 -DHAVE_LSTAT64=1 -DHAVE_FLOCKFILE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STRTOK_R=1 -DHAVE_LANGINFO_CODESET=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk2\" -DMOZ_WIDGET_GTK2=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_X11=1 -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DMOZ_PHOENIX=1 -DMOZ_XUL_APP=1 -DMOZ_APP_NAME=\"firefox\" -DMOZ_ENABLE_XFT=1 -DMOZ_ENABLE_COREXFONTS=1 -DMOZ_EXTRA_X11CONVERTERS=1 -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DACCESSIBILITY=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DHAVE_GSSAPI_GSSAPI_H=1 -DMOZ_MATHML=1 -DMOZ_LOGGING=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DNS_PRINT_PREVIEW=1 -DNS_PRINTING=1 -DMOZ_ACCESSIBILITY_ATK=1 -DMOZILLA_LOCALE_VERSION=\"1.8a\" -DMOZILLA_REGION_VERSION=\"1.8a\" -DMOZILLA_SKIN_VERSION=\"1.5\" -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT ../../../../mozilla/gfx/src/ps/nsPostScriptObj.cpp cc-1253 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.h, Line = 289 The declaration of a member with the same name as its class is invalid. nsFontPS *fontps; ^ cc-1552 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp, Line = 947 The variable "rv" is set but never used. nsresult rv; ^ cc-1020 CC: ERROR File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp, Line = 1064 The identifier "nsXftFaceRequester" is undefined. fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester, ^ cc-1552 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp, Line = 1360 The variable "leading" is set but never used. nscoord leading, emHeight, emAscent, emDescent; ^ cc-1253 CC: WARNING File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.h, Line = 289 The declaration of a member with the same name as its class is invalid. nsFontPS *fontps; ^ cc-1020 CC: ERROR File = ../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp, Line = 2412 The identifier "nsXftFaceRequester" is undefined. error = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester, ^ 2 errors detected in the compilation of "../../../../mozilla/gfx/src/ps/nsFontMetricsPS.cpp". gmake[4]: *** [nsFontMetricsPS.o] Error 2 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/mnt/3/moz/obj2/gfx/src/ps'
did you apply the patch at all? If you did, how come you got an error like this? The identifier "nsXftFaceRequester" is undefined. fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester, Note that the line was removed by my patch.
(In reply to comment #73) > did you apply the patch at all? If you did, how come you got an error like this? > > The identifier "nsXftFaceRequester" is undefined. > > fterror = FTC_Manager_New(mFreeTypeLibrary, 0, 0, 0, nsXftFaceRequester, > > Note that the line was removed by my patch. > sure i did. checked out before, applied the patch and made a firefox. anyway, trying 1.8a4 at the moment. let's see...
I checked out aviary branch @ Mon Oct 25 20:09:33 CDT 2004, applied patch 8 and I get these failures: Hunk #1 FAILED at 1024. Hunk #2 FAILED at 1045. Hunk #3 FAILED at 1114. Hunk #4 FAILED at 2377. 4 out of 4 hunks FAILED -- saving rejects to file gfx/src/ps/nsFontMetricsPS.cpp.rej patching file gfx/src/ps/nsFontMetricsPS.h Hunk #1 FAILED at 337. Hunk #2 FAILED at 471. 2 out of 2 hunks FAILED -- saving rejects to file gfx/src/ps/nsFontMetricsPS.h.rej I've been using the same commands as in the past to apply the patch with no problem. First I saw this was about 3 days ago I think.
Comment on attachment 162261 [details] [diff] [review] patch for gtk2+xft only Jshin, this patch look OK for me. I test it to print 27000 Chinese characters with GB18030 encoding, the performance seems not regressive. sorry for late reply.
Comment on attachment 162261 [details] [diff] [review] patch for gtk2+xft only Ervin, thanks for testing. Can you add 'r' flag to this patch? In my test, the perf. loss couldn't be missed although tolerable. Perhaps, we're just applying slightly different metrics to the same phenonmenon :-). Anyway, if there's any need to deal with perf., I'll do it after landing this.
Attachment #162261 - Flags: review?(blizzard) → review?(Ervin.Yan)
jshin: I have no permission to edit the attachment 162261 [details] [diff] [review]. maybe you need ask someone else to give "r=" flag for your this patch.
Ervin, can you go through the patch to see if there's anything wrong and let me know the result? Then, I'll flag it per your review.
Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4 without this bug fixed.
Flags: blocking-aviary1.0?
(In reply to comment #80) > Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4 > without this bug fixed. As I wrote in my reply to your query a week ago, that's not the case (although I like to fix this bug asap and like to get your support :-)) *unless* you want to compile with '--enable-freetype2'. (So far, RedHat hasn't enabled freetype2 in any of Mozilla builds made for RHEL and FCs). Note that my patch for bug 190031 hasn't been landed in aviary-1.0/mozilla 1.7 branches so that you don't need attachment 162261 [details] [diff] [review].
(In reply to comment #80) > Asking for consideration here: Firefox 1.0 will fail to compile on FC3 and RHEL4 > without this bug fixed. That may be so, but even without the fix, the binaries provided by mozilla.org will run just fine on FC3, won't they? If so, then I don't see why this bug should be a blocker. It should be high priority (for the reason you mentioned), but not a blocker, IMO.
> *unless* you want to compile with '--enable-freetype2'. note that this is the default...
(In reply to comment #83) > > *unless* you want to compile with '--enable-freetype2'. > > note that this is the default... Actually, RedHat has always compiled their Mozilla builds with '--disable-freetype2'. So what I meant was that 'unless you enable freetype2 by not adding '--enable-freetype2'.
(In reply to comment #84) > '--disable-freetype2'. So what I meant was that 'unless you enable freetype2 by > not adding '--enable-freetype2'. You mean --disable-freetype2
jshin, I have go through the patch in attachment 162261 [details] [diff] [review], they are all OK for me. Thanks.
Comment on attachment 162261 [details] [diff] [review] patch for gtk2+xft only flagging with 'r' per Ervin's review. (thanks).
Attachment #162261 - Flags: review?(Ervin.Yan) → review+
Ervin, can you also test 'patch part2' (for builds with '--enable-freetype2') attachment 162272 [details] [diff] [review]? I ran out of the disk space to build an optimized build with freetype2 enabled. (as I wrote before, with a debug build, it's sorta hard to tell the perf. loss). This patch affects the screen rendering (which is more critical than printing) as well. Well, not many people are interested in freetype builds any more. Nonetheless, I don't wanna make it regress perf-wise .
got the following with a current firefox checkout (normal head, not aviary): Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |? gfx/src/ps/.nsType8.cpp.swp |? gfx/src/ps/UnBatang.raw |? gfx/src/ps/nsType8.cpp.new |? gfx/src/ps/output.ps |Index: gfx/src/ps/nsFontMetricsPS.cpp |=================================================================== |RCS file: /cvsroot/mozilla/gfx/src/ps/nsFontMetricsPS.cpp,v |retrieving revision 1.45 |diff -u -7 -p -r1.45 nsFontMetricsPS.cpp |--- gfx/src/ps/nsFontMetricsPS.cpp 20 Aug 2004 09:11:25 -0000 1.45 |+++ gfx/src/ps/nsFontMetricsPS.cpp 15 Oct 2004 22:55:11 -0000 -------------------------- Patching file gfx/src/ps/nsFontMetricsPS.cpp using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] n Apply anyway? [n] Hunk #1 ignored at 1024. Hunk #2 ignored at 1045. Hunk #3 ignored at 1114. Hunk #4 ignored at 2377. 4 out of 4 hunks ignored--saving rejects to gfx/src/ps/nsFontMetricsPS.cpp.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: gfx/src/ps/nsFontMetricsPS.h |=================================================================== |RCS file: /cvsroot/mozilla/gfx/src/ps/nsFontMetricsPS.h,v |retrieving revision 1.26 |diff -u -7 -p -r1.26 nsFontMetricsPS.h |--- gfx/src/ps/nsFontMetricsPS.h 20 Aug 2004 09:11:25 -0000 1.26 |+++ gfx/src/ps/nsFontMetricsPS.h 15 Oct 2004 22:55:12 -0000 -------------------------- Patching file gfx/src/ps/nsFontMetricsPS.h using Plan A... Hunk #1 failed at 337. Hunk #2 failed at 471. 2 out of 2 hunks failed--saving rejects to gfx/src/ps/nsFontMetricsPS.h.rej done
jshin: I will test the patch part2 these days and give you the result.
we may be able to add this to the branch after 1.0 but the patch is large and we're not going to block on this. distributors are encouraged to add this or similar patch to their builds if needed.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Attachment #162261 - Flags: superreview?(dbaron) → superreview?(bryner)
*** Bug 257160 has been marked as a duplicate of this bug. ***
Attachment #162261 - Flags: superreview?(bryner) → superreview+
attachment 162261 [details] [diff] [review] was landed.
*** Bug 262263 has been marked as a duplicate of this bug. ***
Comment on attachment 162272 [details] [diff] [review] patch part 2 (for builds with '--enable-freetype2' ) FYI, this patch fixes my builds on Fedora Core 3 w/2.6.9 kernel.
Comment on attachment 162272 [details] [diff] [review] patch part 2 (for builds with '--enable-freetype2' ) According to my *very unscientific* test (just browsing a dozen web sites in English, Chinese, Japanese, and Korean) with and without this patch, we don't have to worry about perf. loss much. I'll take a profile with and without the patch.
*** Bug 271761 has been marked as a duplicate of this bug. ***
I finally took profiles of two optimized builds (one with and the other without attachment 162272 [details] [diff] [review] applied. actually, I was leaking mFace so that I filled it up). With the patch applied (no glyph image cache utilized), about a fifth of the total running time was spent in nsFreeTypeXImage::DrawString() (and functions called by it) while the figure is about 5% without the patch. A similar increase (3% -> 12%) was observed for nsFreeTypeFont::GetWidth. In both cases, LoadGlyph() was responsible for about 90% of time. So, glyph image caching is rather critical. Here comes my dillemma. Given that these days few Linux users use X11core+FT2 builds, is it worth adding our own glyph caching?
for the record, I'm uploading the profiling results with and without attachment 162272 [details] [diff] [review] applied.
Flags: blocking1.8b?
This patch (part 2) fixes build on Slackware current.
Flags: blocking1.8b? → blocking1.8b-
Asa: why? This is a ready to go patch, fixing the bug, and it would be great to have it for beta cycle to test if this will not regress. I can't find any reason to leave this not checked in :(
it doesn't have reviews, and there seems to be some severe perf issues associated with the patch, isn't that reason enough?
On a 'modern' machine, it's not so noticable (before taking a profile, I didn't notice it on my P3 800MHz, 512MB). Anway, I rolled out my own 'glyph/font cache', but have had a trouble making it work right. Actually, Mozilla keeps crashing in ft_new_glyph() with my patch (not uploaded). I'll try to get this done before 1.8beta... asa, how much do we care about the perf. of X11core/freetype2 build (on Linux)? On linux, only few would use such a build these days (well, some people don't like Xft) although it's still the default build config for the suite. [1] Is it important to embedders? If not, we may just go ahead with the current patch pending r/sr (I'll ask for r/sr later if we decide we don't care about the perf.) [1] With dbaron's recent fix of a long standing Xft-build crash, it may be finally time to switch to Xft.
Target Milestone: --- → mozilla1.5alpha
*** Bug 281166 has been marked as a duplicate of this bug. ***
(In reply to comment #104) > *** Bug 281166 has been marked as a duplicate of this bug. *** Well, but _Sunbird_ fails to *run* on a FT 2.1.8 machine while here's we talk only about _Firefox_ fails to *compile*.
*Birds, FF, and Mozilla suite all share the same Gfx code. Note that this bug is filed under 'Core : Gfx'.
The issue in both cases is that we use freetype APIs that aren't available any longer on some systems. Whether we detect it at compile time or runtime is not really interesting here. Is "patch part 2" obsolete, here, or should it have review requests associated with it?
It still works, but I'm waiting for some 'policy' input from drivers or some people like that. See comment #98 and comment #103.
If you have questions for drivers, you're best to mail drivers@mozilla.org; bugmail's a bad way to get policy issues discussed properly.
(In reply to comment #107) > The issue in both cases is that we use freetype APIs that aren't available any > longer on some systems. Whether we detect it at compile time or runtime is not > really interesting here. But why does a Thunderbird 1.0 binary print without problems where a Sunbird 0.2 binary does "crash"?
Because they're different from different branch-points, I suspect. Reading the code might tell you more; I'm relatively confident that this bug is isomorphic to the one I dup'd here.
(In reply to comment #111) > Because they're different from different branch-points, I suspect. Reading the > code might tell you more; I'm relatively confident that this bug is isomorphic > to the one I dup'd here. Yes, I share your opinion. But: It might be that Sunbird and Thunderbird/Firefox use different compile options so that changing the compile options in Sunbird can solve the bug for the user temporaraly. If I look at the first reporting date, I'll suspect that the bug will be fixed in ~ 2 month. :(
(In reply to comment #111) > Because they're different from different branch-points, I suspect. TB 1.0 is built with gtk2 + xft and it doesn't rely on FT2 at all. Freetype printing in gtk2+xft was added in bug 190031 after aviary 1.0 branch was cut in last May. As for SB 0.2, there are two possibilities. If it's built with gtk1 + freetype2, it'll be fixed by my patch part2. If it's built with gtk2+xft, but still has a problem with freetype printing, it's probably because it's built before my patch part1 - attachment 162261 [details] [diff] [review] (that fixed the problem with FT2 printing in gtk2+xft) was checked in > Reading the code might tell you more; I'm relatively confident that this bug is isomorphic > to the one I dup'd here. Yes, you're absolutely right. Bug 281166 is a dupe of this bug whichever (of two possibilites mentioned above) may be the case. In both cases, one can work around the problem by disabling freetype printing (go to 'about:config', look for 'freetype' and you'll see which pref. to set to false). re comment #109 : yeah, I know. I was kinda lazy. I wrote to drivers@....
Comment on attachment 162272 [details] [diff] [review] patch part 2 (for builds with '--enable-freetype2' ) This patch is starting to suffer from bitrot.
*** Bug 284763 has been marked as a duplicate of this bug. ***
*** Bug 284942 has been marked as a duplicate of this bug. ***
*** Bug 288882 has been marked as a duplicate of this bug. ***
What is the status of this bug? I failed to build Mozilla Suite 1.7.6 with Freetype 2.1.9. I can attach the build log from my own mozilla build script if necessary. Does a GTK2+Xft2 build also needs a patch? My (need to be updated) Firefox build is GTK+Xft2 and did not suffer from the FT2 2.1.4 to 2.1.9 migration, unlike my Seamonkey 1.7.5 (which is GTK1+Freetype2) where I lost the font anti-aliasing. I have to update as soon as possible (security!) and I cannot use the official binaries because I changed a lot of things on my Linux system.
(In reply to comment #118) > Does a GTK2+Xft2 build also needs a patch? My (need to be updated) No, it doesn't. The necessary patch (attachment 162261 [details] [diff] [review]) has already been landed. Mozilla 1.7.6/Firefox 1.0.x don't have that patch (because it's not necessary) but should be fine if gtk2+xft is used instead of the default gtk1+freetype2+X11.
This patch modifies the mozilla-1.7.7 release to use freetype 2.1.8 as provided with X-4.5.0. I have run it for a day and it seems OK but of course it needs more testing. The patch also modifies the svg renderer interface file that comes with the release. but because libart is not included, I can't test this at all. It may not even compile. Sorry, but I just don't have time to mess with the CVS version. Apply the patch from the top level mozilla directory with -p1.
(In reply to comment #120) > Created an attachment (id=181857) [edit] > Freetype 2.1.8 patch for mozilla 1.7.7 > > This patch modifies the mozilla-1.7.7 release to use freetype 2.1.8 as provided > with X-4.5.0. I have run it for a day and it seems OK but of course it needs Thanks for the patch, but your approach has already been tried. Due to the incompatible change made by freetype folks, we have some headache here and I decided to take a different approach. See comment #28 and comment #62 (and other related comments). Anyway, it's not a high priority item any more because we chagned the default build option to gtk2 + xft even for suite. Firefox had been built with gtk2+xft for a while when we switched.
It is my understanding that the X guys plan to eliminate Xft in upcoming releases in favor of freetype. That was my main motivation for fixing this now. As has already been pointed out, the freetype guys have made the serious error of changing the ABI without changing the libfreetype version number. This has been further compounded by the release of X-4.5.0 with freetype 2.1.8. The previous version X-4.4.0 had freetype 2.1.4 with the old ABI. So now we're stuck with incompatible versions of libfreetype.so.6, depending on which version of X is installed. If Xft disappears, it seems to me that until the libfreetype version issue is resolved the only viable solution for binary releases to the general public is to statically link libfreetype. At least with this patch, you can statically link a newer version. Static linking of included source can be set as the build default in the source package, with an option to use the system libfreetype. If this option is selected, the configure script tests for a compatible version of libfreetype on the system and dies if it is not available. As time passes and systems are upgraded, the problem will go away (assuming the freetype guys refrain from introducing more ABI changes under libfreetype.so.6). Yours, Joseph
(In reply to comment #122) > It is my understanding that the X guys plan to eliminate Xft in upcoming > releases in favor of freetype. That was my main motivation for fixing this > now. That doesn't make sense. They're not competitors; they're different layers. (As I understand it, Freetype deals with font data, Xft deals with doing client-side font rendering, and fontconfig deals with finding fonts.)
(In reply to comment #122) > It is my understanding that the X guys plan to eliminate Xft in upcoming > releases in favor of freetype. That was my main motivation for fixing this > now. Where did you hear that? As David wrote, it doesn't make any sense.
OK, I misread the documentation and the comment above is silly. Moreover, had I not gotten confused in this way, I would never have bothered to make this patch. Sorry for the noise. Do with the patch as you see fit. However, doing font rendering without Xft does make sense. Xft is a wrapper around freetype, fontconfig, and Xrender. The freetype cache issue aside, it is probably just as easy to access fontconfig directly to select fonts, and to render glyphs directly with freetype. One then has the option of composing an image with the resulting bitmap/graymap using Xrender, or to just pass it to core X when that isn't necessary.
(In reply to comment #125) > One then has the option of composing an > image with the resulting bitmap/graymap using Xrender, or to just pass it to > core X when that isn't necessary. ...which is a lot of code. It's also already been written in a library called Xft.
Since it seems that no one has mentioned it, I wish to report that Firefox 1.0.4 seems to be no longer compilable with Freetype2 "9.7.3", with the same symptoms; the patch also fails to apply. (Mozilla 1.0.0 was compilable.)
*** Bug 294883 has been marked as a duplicate of this bug. ***
Hello, all: I am compiling mozilla 1.7.8 in my FreeBSD 5.3 (i386), in which FreeType 2.1.9 is installed. There are so many patches here. Which one shall I apply? If I want to build with the option "--enable-default-toolkit=gtk2 --enable-xft - -enable-freetype2", does that mean I must apply "patch for gtk2+xft only" (162261) and "patch part 2 (for builds with '--enable-freetype2' )" (162272)? Or just one of them is enough? I am really lossed in this long thread. Thank you,
(In reply to comment #129) > If I want to build with the option "--enable-default-toolkit=gtk2 --enable-xft - > -enable-freetype2", does that mean I must apply "patch for gtk2+xft only" > (162261) and "patch part 2 (for builds with '--enable-freetype2' )" (162272)? You can not enable xft and freetype2 at the same time.
(In reply to comment #130) > You can not enable xft and freetype2 at the same time. I know this should be a separate bug, but as recent as 1.0.0 this was "possible" (i.e., it did not generate compile time errors).
(In reply to comment #132) > 1.0.x is not "recent" What do you mean by that? The most current version is 1.0.4 but 1.0.x is "not recent"? We can't have the case where the most recent version is not recent!
(In reply to comment #133) > (In reply to comment #132) > > 1.0.x is not "recent" > > What do you mean by that? The most current version is 1.0.4 but 1.0.x is "not > recent"? 1.0.4 is the most recent *released* version, but the development efforts are put on the trunk. 1.0.x branched off the trunk more than a year ago. Anyway, you're right that it's possible to have both xft and freetype for 1.0.x branch. The patch to block freetype from being enabled with xft+gtk2 was landed only on the trunk. (for bug 190031) http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&file=configure.in&rev2=1.1361&rev1=1.1360 Anyway, can you tell me why you wanna enable freetype for gtk2+xft? Is it for printing? Then, I'll tell you what patches to apply (there are a few patches to apply)
(In reply to comment #134) > Anyway, can you tell me why you wanna enable freetype for gtk2+xft? Is it for > printing? Then, I'll tell you what patches to apply (there are a few patches to > apply) Actually, I don't mind whether freetype2 is enabled or not. What I care is to successfully compile mozilla 1.7.8 by the option "--enable-default- toolkit=gtk2 --enable-xft". Can you tell me which patch(es) I should apply to the src? Thanks,
(In reply to comment #135) > Actually, I don't mind whether freetype2 is enabled or not. What I care is to > successfully compile mozilla 1.7.8 by the option "--enable-default- > toolkit=gtk2 --enable-xft". > Can you tell me which patch(es) I should apply to the src? Btw, my OS is FreeBSD 5.3 (i386), on which FreeType 2.1.9 was installed before. With the above mentioned configure options, I compiled the src and met the following error: ------------------------------------------------ In file included from nsFreeType.h:39, from nsFreeType.cpp:48: ../../../dist/include/gfx/nsIFreeType2.h:53: error: `GetImageCache' declared as a `virtual' field ...[snipped] nsFreeType.cpp:392: error: `FTC_Image_Cache' was not declared in this scope nsFreeType.cpp:392: error: `aCache' was not declared in this scope nsFreeType.cpp:393: error: expected `,' or `;' before '{' token nsFreeType.cpp: In member function `void nsFreeType2::ClearGlobals()': nsFreeType.cpp:429: error: `mImageCache' undeclared (first use this function) nsFreeType.cpp:429: error: (Each undeclared identifier is reported only once for each function it appears in.) nsFreeType.cpp: In member function `PRBool nsFreeType2::InitLibrary()': nsFreeType.cpp:668: error: `mImageCache' undeclared (first use this function) gmake[4]: *** [nsFreeType.o] Error 1 gmake[4]: Leaving directory `/usr/src/mozilla/gfx/src/freetype' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/usr/src/mozilla/gfx/src' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/usr/src/mozilla/gfx' gmake[1]: *** [tier_9] Error 2 gmake[1]: Leaving directory `/usr/src/mozilla' gmake: *** [default] Error 2 ------------------------------------------------ Pls advise me on which patch(es) to apply, Thanks.
I've already answered off-line, but to prevent others from asking the same question again (in addition, because the build document, having been revised for the trunk, doesn't mention about this), I'll answer here. If you don't care about printing in gtk2+xft, just disable freetype2 using '--disable-freetype2' (in mozconfig, it's 'ac_add_options --disable-freetype2'). You don't need any patch for the 1.0.x/1.7.x branches.
(In reply to comment #137) > I've already answered off-line, but to prevent others from asking the same > question again (in addition, because the build document, having been revised for > the trunk, doesn't mention about this), I'll answer here. If you don't care > about printing in gtk2+xft, just disable freetype2 using '--disable-freetype2' > (in mozconfig, it's 'ac_add_options --disable-freetype2'). You don't need any > patch for the 1.0.x/1.7.x branches. (I'm attempting to compile Firefox 1.0.4 so I can try to implement a fix to the old "geometry" resource problem--hopefully in a way that can be accepted into the code base.) Does disabling freetype2 prevent any printing, assuming the default toolkit is gtk2/xft, or is the impact less severe that that? I do need to print, but if the only impact is that the characters might have slightly different appearance and/or spacing, I could live with that.
(In reply to comment #138) > Does disabling freetype2 prevent any printing, assuming the default toolkit is > gtk2/xft, or is the impact less severe that that? It doesn't unless you need to print characters other than Latin. Non-latin characters can be printed, too, but the result is not so good. Anyway, those who care about that can apply my latest patch to bug 215219 to 1.0.x branch source. (it does more than just enabling a better quality printing)
These patches are not meeting this problem. With the freetype2 build they disable the lib when >2.1.8 is used and with <2.1.8 they cause anomalies. I dont think its fair to really say the issue is the versioning (I assume you expect them to call this freetype3) when the makefile doesnt actually use the the freetype-config it calls. Freetype is a non-issue for every other build that uses it and can be built w/ either version. The major action of the lib has not as far as I understand, only the names of a couple functions. It takes a real CS to jam up a major project that has enough headaches as is for written code as piddly as freetype is.
> only the names of a couple functions AIUI the functions were removed, not renamed
*** Bug 301051 has been marked as a duplicate of this bug. ***
Hi, I'm having a problem with the freetype apparently asswell. I get the following message when compliling: In file included from /home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsDeviceContextPS.h:50, from /home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsDeviceContextPS.cpp:55: /home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:344: error: ' FTC_Image_Desc' is used as a type, but is not defined as a type. /home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:347: error: ' FTC_Image_Cache' is used as a type, but is not defined as a type. /home/cputter/Sandbox_Alpha/mozilla/gfx/src/ps/nsFontMetricsPS.h:481: error: ' FTC_Image_Desc' is used as a type, but is not defined as a type. gmake[5]: *** [nsDeviceContextPS.o] Error 1 gmake[5]: Leaving directory `/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx/src/ps' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx/src' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu/gfx' gmake[2]: *** [tier_9] Error 2 gmake[2]: Leaving directory `/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu' gmake[1]: *** [default] Error 2 gmake[1]: Leaving directory `/home/cputter/Sandbox_Alpha/mozilla/objdir-x86_64-linux-gnu' gmake: *** [build] Error 2 I'm running Suse 9.3, on Athlon 64. Here's my mozconfig file: # # See http://www.mozilla.org/build/ for build instructions. # # Options for client.mk. mk_add_options MOZ_CO_PROJECT=calendar mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-x86_64-linux-gnu # Options for 'configure' (same as command-line options). ac_add_options --enable-application=calendar ac_add_options --disable-mailnews ac_add_options --disable-tests ac_add_options --enable-optimize ac_add_options --enable-static ac_add_options --disable-debug ac_add_options --disable-shared ac_add_options --enable-plaintext-editor-only ac_add_options --enable-necko-protocols=about,http,ftp,file,jar,res ac_add_options --enable-storage ac_add_options --disable-accessibility ac_add_options --disable-activex ac_add_options --disable-activex-scripting ac_add_options --disable-installer ac_add_options --disable-jsd ac_add_options --disable-mathml ac_add_options --disable-necko-disk-cache ac_add_options --disable-oji ac_add_options --disable-view-source ac_add_options --disable-logging ac_add_options --disable-plugins ac_add_options --disable-cookies ac_add_options --enable-default-toolkit=gtk2 ac_add_options --disable-freetype2 ac_add_options --enable-xft Is this related to the same bug, or something totally different?
Product: Core → Core Graveyard
the third patch from the top works well with 1.5.0.12 final (17.26 KB) only required one minor correction and that was all
We now bundle a much later version of Freetype (2.4.6) so I believe this has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: