[PNG icon] PNG Support in Mozilla: Build Notes [OLD!]

Build Notes

Here are some slightly dated notes on building Mozilla. These are very system-specific, but there may be some useful pointers buried in them. Note that a full debug build on the system below requires a partition of around 750 MB and takes 3 hours, not including the time required to do a CVS pull (typically around 45 minutes for a one-week update). Note also that viewer (the barebones browser/renderer) is quite slow on such a system, and apprunner (the Communicator prototype) is even slower.

System configuration:

Built and installed autoconf, automake, libtool in /usr/local/bin and /usr/local/lib. With previously installed libnspr21 (24 Dec 1998) in /usr/local/experimental, attempted to get glib 1.2.0 configuration to detect and use NSPR threads; only detected if patched configure (LDFLAGS and DEFS modified for /usr/local/experimental directory), but compilation failed anyway (GLOCK(GModule) macro -> "g__GModule_lock undeclared"). Reverted to stock configure, built without threads, and installed in /usr/local/experimental:

For gtk+ 1.2.0, did following:

For Mozilla, began with source archive from 4 March 1999 and basically followed Unix build instructions:

This got as far as the "libs" target in layout/html/forms/src before barfing on nsFormControlHelper.cpp. Apparently did the CVS checkout while someone else was busy checking into that directory; fixed by visiting Bonsai and Tinderbox and doing an updated checkout early on 7 March 1999. (Also archived and nuked all of the CVS '?' files except for depend.mk and *.OBJ directories.)

This time the compile (still "libs" target) barfed in editor/base on nsTextEditor.cpp. No clue what's wrong, but the editor is unnecessary, so reconfigured without it:

Yet another "libs" failure, now in xpfe/AppCores/src on nsBaseAppCore.cpp. Again, no clue (random C++ barfage apparently related to forward-referencing an incomplete class)...is XPFE really needed with a GTK-based front end? Ah, Sir Ramiro saves the day. Continued by doing the following:

This time the build succeeded. Wrapped dist/bin/viewer in a small shell script that sets LD_LIBRARY_PATH and tried it on a local HTML file; it popped up a gray window, said ``Going to create the event queue'' and segfaulted with an 11 MB core dump.

Update 1999-03-11:   Pulled updated sources this morning after last night's report by Andrew Volkov that the long-standing OBJECT bug is finally fixed (that is, supposedly Mozilla will now render OBJECT PNGs, JPEGs and GIFs directly without looking for a plug-in or messing with the contents of the OBJECT container). The tree was a lovely shade of green at the time, which seemed a good portent.

The build succeeded with no further tweaking (whew, about time). Running viewer resulted in the following output before dying with a 3 MB core dump due to a charset assertion failure in htmlparser/src/nsScanner.cpp: 

nsComponentManager: Creating Directory /home/roelofs/.mozilla
Going to create the event queue
font refcount: 3
font refcount: 4
font refcount: 5
Using '/util/www/mozilla/dist/bin' as the resource: base
font refcount: 6
Got thew event queue from the service
Calling gdk_input with event queue
Abort (core dumped)

While this was printing to the console, a window popped up and even displayed four menu items (File, Edit, Debug, Tools), two buttons (Forward, Back), and a text-entry window (resource:/res/samples/test0.html), but it vanished almost immediately.

Running apprunner, on the other hand, produced the following console output and then stayed running, albeit with a completely blank window: 

Argument: -progname, ****** Value: /util/www/mozilla/dist/bin/apprunner
iconic  state not set
width was not set
height was not set
Using '/util/www/mozilla/dist/bin' as the resource: base
Got thew event queue from the service
Calling gdk_input with event queue
Reading file...
DocLoaderFactory: Unable to create ContentViewer for content-type: text/xul
OnConnectionsComplete

Giving it an argument (the local URL to this file, which is about as vanilla as HTML gets) resulted in the following: 

apprunner file:///home/roelofs/WWW/pngmoz.html
Argument: -progname, ****** Value: /util/www/mozilla/dist/bin/apprunner
Argument: -url, ****** Value: file:///home/roelofs/WWW/pngmoz.html
URL to load is file:///home/roelofs/WWW/pngmoz.html
iconic  state not set
width was not set
height was not set
Got thew event queue from the service
Calling gdk_input with event queue
Using '/util/www/mozilla/dist/bin' as the resource: base
Reading file...
Abort (core dumped)

The same thing occurred with the remote copy of the page (http://www.libpng.org/pub/png/pngmoz.html, presumably what you are reading right now) and with the Mozilla home page. No time for gdb on apprunner yet, but soon...

Update 1999-03-14:   Again pulled updated sources after noticing that core dump probably had to do with XPCOM, which has been under active development lately:

Fired up viewer with no arguments once more; by golly, it runs! Even better, so does apprunner, which is more or less equivalent to the ``Gecko'' browser Netscape distributed in December 1998. Here are some small screenshots of apprunner rendering the image-PNGs test page and two sections of the object-PNGs test page:


Click to see the full-sized versions.

Note that the doubled penguins (middle screenshot) and paired PNG/JPEG icons (righthand screenshot) are not correct; only the left image in each case should be visible. Greg reopened the original OBJECT bug.

But OBJECTs notwithstanding, a working browser means that Greg can finally get started on improving Mozilla's PNG support, you betcha!

Update 1999-04-06:   The OBJECT bug (1945, above, and also 3692 and 4441) reportedly is fixed. Greg will update his build tonight and see how it looks.

Update 1999-04-08:   After a big CVS pull (around an hour, give or take; modem died in the middle of the first try), an interesting gcc bug (4631), a failed ``make depend'' build, a ``make clobber'' and 94 minutes of non-mailnews rebuilding (222 MB of object files!), Greg finally got a working apprunner again. And lo and behold! The OBJECT bug is indeed eradicated at last--or at least until Greg figures out an even more twisted test case. Hallelujah, etc., etc., and big thanks to both Rick Gessner and Andrew Volkov.


Click to see the full-sized versions.

There is, however, a bug in apprunner's rendering of the nested lists on the PNG home page; this can be seen in the last image, where several lines suddenly unindent all the way to the left margin (bug 5460).

Update 1999-04-17:   Grabbed libIDL 0.6.5 (now required) from ftp://ftp.mozilla.org/pub/mozilla/libraries/source/, compiled and barfed on old version of makeinfo (1.63). Grabbed texinfo 3.12 from ftp://ftp.gnu.org/pub/gnu/texinfo/, compiled and installed, then recompiled libIDL and installed in /usr/local/experimental (as with glib, gtk+ and libnspr3).

More important, Greg finally tracked down source of the PNG interlace bug in Mozilla; it stems from ImageLib modifying a libpng row buffer in place (by stripping the alpha bytes out of an RGBA row--this happens in il_emit_row() in scale.cpp). That's bad, because libpng returns the same buffer for replicated lines in an interlaced image--for example, the first row is returned a total of 8 times in the first interlaced pass, and the 4:3 ``compression'' gets repeated 7 times even though the alpha values are gone after the first round. The fix is to allocate a couple of working row buffers in the PNG decoder (as is done for GIF), but that can wait until after the new ImageLib code gets checked in.

Update 1999-04-23:   Pulled a new tree, including ImageLib 2.0, and did a full clobber build (102 minutes). Apprunner can't find any libjpeg and libpng functions even though both libraries are statically linked in; as a result, it won't display any JPEG or PNG images (bug 5459). This seems to be a problem in the dynamic registry/XPCOM stuff.

Update 1999-04-30:   Boy, bug 5459 caused many headaches this week. The original problem was fixed by some minor modifications to Makefile.in in the modules/libimg/pngcom and modules/libimg/jpgcom directories, and for Red Hat / glibc-based folks, that appears to have fixed everything. But Greg's libc5-based system still won't touch his system libpng.so.2, even though that's what it links libnspng.so against. PNG images simply don't get rendered. Using the Mozilla-built copy of libpng.so (linked as libpng.so.2) works just fine, however. Maybe this is related to the fact that the system library is an optimized build while the Mozilla-built one is a debug version? To top it off, ldd 1.9.5 doesn't work on shared objects even though ld.so 1.9.5 will load them for any app but Mozilla.

And regardless of which libpng is installed, OBJECT images of any flavor fail to display (bug 5829).

Update 1999-05-01:   OK, headaches finally eliminated. Mozilla always compiles with its own png.h and pngconf.h even when it links against a system libpng.so (bug 5842). On top of that, Mozilla's pngconf.h is from libpng 0.95 even though the rest of its libpng files are from 1.0.2 (bug 5841), and this is specifically what causes the incompatibility with the system libpng.so.2 on Greg's system.

Update 1999-05-06:   Oops. The problem of Mozilla compiling with its own PNG headers (bug 5842) turns out to have been pilot error. You have to do "make clobber_all" after switching from Mozilla libpng to system libpng; "make clobber" doesn't remove the symlinks in dist/include (or anything under dist, for that matter). Greg did a clobber_all build with no other changes, and indeed the system PNG header files were used (along with the system PNG library). Nothing broke, either. Bug 5842 is therefore closed out as ``resolved/invalid.''

Update 1999-08-08:   The Necko landing (rewrite of Mozilla's networking code) was disastrous for those with "old" systems; even Linux glibc 2.0 systems (e.g., Red Hat 5.2) are hosed, and the decision is to ignore them and concentrate solely on glibc 2.1. (This has to do with threads and race conditions while dynamically loading shared objects.) Greg's libc5 system is positively archaic by comparison, and unsurprisingly, many things are broken: apprunner doesn't work at all, viewer fails to load file:, ftp: and resource: URLs (the latter of which includes the stylesheet stuff that makes HTML render as HTML--bug 11018), and PNG images don't render at all anymore (bug 11019). Sigh. But pip@dds.nl discovered that running viewer at a higher-than-normal priority (or, for Greg, simply running it as root) makes it load file/ftp/resource URLs just fine. And with Greg's version of the PNG code, PNG images load OK, too. Whew...progress can once again be made.

[primary site hosted by SourceForge] Last modified 14 March 2009.

Copyright © 1999-2000 Greg Roelofs.