Closed Bug 140628 Opened 22 years ago Closed 22 years ago

build bustage using xft and freetype > 2.0.8

Categories

(SeaMonkey :: Build Config, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: pierre, Assigned: blizzard)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID:    

Hi,

I configured with --enable-xft and i got this error when compiling :

[...]
gmake[2]: Entering directory `/tmp/mozilla/other-licenses/Xft'
gmake[3]: Entering directory `/tmp/mozilla/other-licenses/Xft/Xrender'
../../../config/nsinstall -R -m 644 libXrender.a ../../../dist/lib
gmake[3]: Leaving directory `/tmp/mozilla/other-licenses/Xft/Xrender'
gmake[3]: Entering directory `/tmp/mozilla/other-licenses/Xft/fontconfig'
gmake[4]: Entering directory `/tmp/mozilla/other-licenses/Xft/fontconfig/fontconfig'
gmake[4]: Leaving directory `/tmp/mozilla/other-licenses/Xft/fontconfig/fontconfig'
gmake[4]: Entering directory `/tmp/mozilla/other-licenses/Xft/fontconfig/src'
fccharset.c
gcc -o fccharset.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\" -DOJI
-DFC_FALLBACK_FONTS=\"/usr/X11R6/lib/X11/fonts/Type1\" 
-I../../../../dist/include/freetype2 -I../../../../dist/include/fontconfig
-I../../../../dist/include/expat -I../../../../dist/include/fontconfig
-I../../../../dist/include -I/tmp/mozilla/dist/include/nspr     
-I/usr/X11R6/include   -fPIC -I/usr/X11R6/include -Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -pedantic -Wno-long-long -O3 -march=i686
-fshort-wchar -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_root -DTRACING -g -O
-I/usr/local/include -I/usr/local/include/freetype2  -I/usr/X11R6/include
-include ../../../../config-defs.h -DMOZILLA_CLIENT -Wp,-MD,.deps/fccharset.pp
fccharset.c
fccharset.c: In function `FcFreeTypeCharIndex':
fccharset.c:906: warning: comparison between signed and unsigned
fccharset.c:915: warning: comparison between signed and unsigned
fccharset.c:924: warning: comparison between signed and unsigned
fccharset.c: In function `FcFreeTypeCharSet':
fccharset.c:1007: warning: comparison between signed and unsigned
fccharset.c:1046: too few arguments to function `FT_Get_Next_Char'
fccharset.c:1073: too few arguments to function `FT_Get_Next_Char'
gmake[4]: *** [fccharset.o] Error 1
gmake[4]: Leaving directory `/tmp/mozilla/other-licenses/Xft/fontconfig/src'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/tmp/mozilla/other-licenses/Xft/fontconfig'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/tmp/mozilla/other-licenses/Xft'
gmake[1]: *** [tier_9] Error 2
gmake[1]: Leaving directory `/tmp/mozilla'
gmake: *** [default] Error 2



It would be great if you could help me with this !

Best regards,

Pierre.


Reproducible: Always
Steps to Reproduce:
1.Connfigure with --enable-xft
2.Compile
looks like a dupe of bug 130476.  what version of freetype do you have?
I have freetype 2.1.0 installed.
you might have more luck if you use source from after 4/25/2002

http://bonsai.mozilla.org/cvsquery.cgi?file=fccharset.c&date=month
Blizzard, are you planning on landing the xft code for 1.0 or should I remove
that configure option?
Assignee: seawood → blizzard
*** Bug 140728 has been marked as a duplicate of this bug. ***
I imported the most recent code into the tree a while ago.  Looks like he's
picking up a system freetype instead of the in tree version.

The gfx/ bits probably aren't going to land in the 1.0 time frame, unless a
miracle happens.  Please don't remove the xft configure option though, it's very
useful for testing.  Maybe we can label it as "doesn't work" or something?
It's a proven fact that people don't read :-p , so I'm more inclined to remove
the    configure option but leave the build variable.  Then you can just set the
variable in your mozconfig (or rpm script) in lieu of the configure option.  If
it doesn't work and we don't plan on making it work for 1.0, then it shouldn't
be a user visible option. 

*Sigh* If freetype 2.1.0 isn't compatible with 2.0.x then we need to beef up the
configure tests to only check for the 2.0.x series.  
I believe we want to use the 2.1.0+ definition of FT_Get_Next_Char (3 args)
not the older version (2 args).

Pierre: could you get a more current version of FreeType2 and see if the
problem still exists?
I believe even FT_Get_Next_Char in 2.0.9 has 3 args.
I have the more up-to-date version of freetype (2.1.0).
The only incompatibility in freetype is between 1.x and 2.x series I think.
Yes, that function definitely changed in 2.0.9.  I imported 2.1.0 into the
Mozilla tree.

So, Chris, what about those of us that only use configure?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Problem compiling mozilla 1.0.rc1 → Problem compiling mozilla 1.0.rc1 with xft
*** Bug 144081 has been marked as a duplicate of this bug. ***
> So, Chris, what about those of us that only use configure?

env MOZ_ENABLE_XFT=1 ./configure --prefix=/foo


*** Bug 147214 has been marked as a duplicate of this bug. ***
Summary: Problem compiling mozilla 1.0.rc1 with xft → build bustage using xft and freetype >= 2.0.8
Summary: build bustage using xft and freetype >= 2.0.8 → build bustage using xft and freetype > 2.0.8
Keywords: mozilla1.0
This just keeps getting uglier.  It seems as though none of the versioning
identifiers used by .m4 or freetype-config were bumped in the 2.1.0 release.
They still use the same identifier as 2.0.8; the identifier is 8.0.2.  The one
from th e freetype-2.0.3 was 6.1.0.  That seems a bit odd as it seems that the
identifiers are generally useless/out-of-date unless there was a major library
incompatibilty between 2.0.3 and 2.0.8 (I don't think that there was).
The way the freetype people use identifiers with 2.1.0 is buggy.
To clarify the situation, I advise you to read this thread :

http://www.freetype.org/pipermail/freetype/2002-April/thread.html#2160
(or http://www.freetype.org/pipermail/freetype/2002-April/002160.html and the
following emails)

I believe this one is fixed - I've built an xft-enabled Mozilla with a very
recent freetype version.
Yeah, this is a system config issue, really.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
v wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.