Closed Bug 126713 Opened 23 years ago Closed 23 years ago

install FreeType2 on Linux/Unix build systems to enable TrueType in client

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.1alpha

People

(Reporter: bstell, Assigned: bstell)

Details

(Keywords: intl, Whiteboard: in progress)

Attachments

(2 files)

The TrueType Linux/Unix support code added in bug 116147 requires the FreeType2 library to be on the build machine. (To avoid breaking the builds, configure checks if the lib is there and if not disables the code.) To make this code available to users we will need to install FreeType2 (at least the headers) on the appropiate build systems.
Keywords: intl
QA Contact: ruixu → ylong
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Umm, doesn't this bring in the problem of an additional runtime dependency? Unless you're talking about statically linking against libfreetype which we currently don't do.
can we do a dlopen at runtime and enable/disable accordingly?
There are 3 "off" switches for this code: 1) at compile time if the headers and libs are not on the build system the MOZ_ENABLE_FREETYPE2 define is not set and the code is #ifdef'd out. 2) At run time if PR_LoadLibrary fails to load libfreetype.so then the code is never called. 3) There is a pref to enable this (off by default).
Aki installed FreeType 2.0.4 on the SeaMonkey tinderbox system Comet yesterday at about 5pm.
installed on autobahn and bawb. touched configure and configure.in on autobahn's depend and clobber tinderboxen... we'll see if that's enough to trigger it to reconfigure.
-> nsbeta1
Keywords: nsbeta1
Summary: install FreeType2 on Linux/Unix build systems to enable TrueType in client → (in progress) install FreeType2 on Linux/Unix build systems to enable TrueType in client
Whiteboard: in progress
In the configure, we're running gcc -o conftest -pthread -I/usr/local/include/freetype2 -I/usr/X11R6/include conftest.c -L/usr/local/lib -lfreetype -ldl -lm -lc 1>&5 But we're getting ./conftest: error in loading shared libraries: libfreetype.so.6: cannot open shared object file: No such file or directory And it's there: bawb /builds/client/linux22/seamonkey/mozilla % ls -l /usr/local/lib total 2096 -rw-r--r-- 1 root root 1363116 Feb 25 11:46 libfreetype.a -rwxr-xr-x 1 root root 726 Feb 25 11:46 libfreetype.la* lrwxrwxrwx 1 root root 20 Feb 25 11:46 libfreetype.so -> libfreetype.so.6.1.0* lrwxrwxrwx 1 root root 20 Feb 25 11:46 libfreetype.so.6 -> libfreetype.so.6.1.0* -rwxr-xr-x 1 root root 768530 Feb 25 11:46 libfreetype.so.6.1.0* Manually setting the LD_LIBRARY_PATH to include /usr/local/lib is a workaround.
Either using LD_LIBRARY_PATH or adding /usr/local/lib to ld.so.conf isn't a workaround, it's a solution: you're asking Mozilla to check libraries that aren't in your default runtime linker path, so you're going to need to help it find them.
ok, putting in softlinks to /usr/local/lib/libfreetype.so.6.1.0 in /usr/lib gets the configure working.
TrueType now available in linux x86 mozilla and netscape on to other platforms
installed on como, messina, palermo, salerno... had to build with /tools/ns/bin/gcc because ansic was too strict and it wouldn't build. should show up next cycle, as they're all clobber builds. torino isn't letting me in... seems hung.
salerno has gone red because of freetype2... not sure if y'all want me to back out or if you want a shot at fixing the problem first.
would it be okay if we look at in the morning?
for hpux 10.20 & 11.00 why don't we get freetype from http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/freetype-2.0.6/ Unfortunately IBM's is only at 1.31 :-( http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html (but the aix tinderbox isn't even working so no big deal there) The only issue now is that the libs will be in a different place than /usr/local for hpux & aix...
> The only issue now is that the libs will be in a different place than > /usr/local for hpux & aix... The configure.in script uses AC_CHECK_FT2 from the FreeType2 freetype2.m4 script which uses 'freetype-config --libs' to find the libs. Does the command 'freetype-config --libs' report the correct location? If so the moz should find it.
> for hpux 10.20 & 11.00 why don't we get freetype from ... As long as 'freetype-config --version' reports at least 6.1.0 this should be okay.
I am updating the HP machines right now using "connect's" prebuilt libs (and it the version is > 6.1.0) I updated the path on salerno (commercial) and restarted the tinderbox.
Attached patch HP-UX patchSplinter Review
Here is the fix for hp-ux commercial (--enable-debug) tinderbox
On HP, the sharedlib suffix is .sl, not .so so we should never hardcode .so. By putting in "libfreetype" MOZ_DLL_SUFFIX; the preprocessor will do the correct thing. NOTE, one or 2 of the bsd's in configure define MOZ_DLL_SUFFIX to .so.<something> I can't do anything about that.
Aki/Jim: Can we list all the machines that FreeType was installed on?
see comment #4, comment #5, comment #11 for my installs.
HP-UX update: I installed/reinstalled freetype2 on messina, como, pisa, salerno, palermo which I got from http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/freetype-2.0.6/ this puts the package in /opt/freetype. Development: -You need to link/copy /opt/freetype/include/ft2build.h into /usr/include -Have /opt/freetype/bin in your path Runtime: -Have /opt/freetype/lib in your SHLIB_PATH
I suggest we implement jdunn's suggestion (via private AIM channel) and do something like this: if (!PR_LoadLibrary(libfreetype$MOX_DLL_SUFFIX) if (!PR_LoadLibrary(gFreeTypePrefName) ...
Do we also want to check in the "mozilla" script if freetype-config is in $PATH, and if so add `freetype-config --prefix`/libs to our LD_LIBRARY_PATH/SHLIB_PATH/LIBPATH? Using --prefix seems simpler than using --libs and having to "| awk '{print $1}' | cut <remove -L>"
err... ignore comment #24 chances are script will only be on machines that have the freetype-development package on it, most users (I suspect) will just install the freetype runtime package so this change isn't probably worth the effort.
take out nsbeta1 since this is a library instation issue.
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
move target to 1.1
Target Milestone: mozilla1.0 → mozilla1.1
Could i please get some confirmation whether True type font support was added to the Linux Mozilla 0.9.9 release. The release notes say that it is but with NS_FONT_DEBUG=400 I get "freetype not compiled in, nsFreeType.cpp 65". Can the release notes please be altered to reflect this? Thanks
=P Wasn't built in to the 0.9.9 binaries... I added the libs to the trunk build machines early on, but we use different machines for the branch.
We always ship from a branch. Can we get these libs installed on the branch machines as well?
aki, would you respin the branch builds
Could somebody please point out which if any 0.9.9 packages that have TrueType/Freetype support built in? I'm getting tired of stressing moz's ftp and re-re-re-installing to no avail...
installed on goldie, respinning 0.9.9 linux build.
also installed on foxhound.
0.9.9 rereleased with freetype2.
Any chance the RedHat 7x RPMS will include freetype support?
Thomas: you will need to contact Redhat about that. Perhaps blizzard knows.
Marking closed. This has been done for a long time
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Mark as verified - enable True Type is availible from client now.
Status: RESOLVED → VERIFIED
take the "(in progress)" comment out of the title.
Summary: (in progress) install FreeType2 on Linux/Unix build systems to enable TrueType in client → install FreeType2 on Linux/Unix build systems to enable TrueType in client
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: