With a current apprunner build on FreeBSD, JPEG and PNG images aren't displayed -- or, rather, they seem to be displayed as one-pixel dots. I don't know if this is the old shared library problem again (libnspng.so needing to pull in libpng.so.2) or something else. I *do* have both libpng.so and libjpeg.so installed in my system, and configure is using them. I'm testing this by going to the "JPEG images" and "PNG images" tests in the Debug menu.

Yep. it sounds like the lib problem again. If you see gif's, the decoder component load is working. Sometimes this happens if you have files left over from previous builds. Local clobbers won't fix it. Try a top level make with realclean. Take a look at bug#5842.

I did a clobber_all (the same as realclean, I believe), and rebuilt with a fresh tree from this morning. The problem's still there. Yes, GIFs are working fine.

Another observation -- running ktrace on the binary shows that /usr/local/lib/libpng.so.2 *is* getting loaded, right after libnspng is -- or at least it's getting an open(), read(), and mmap(), which is all the ktrace will tell me. So I guess the problem must be more complicated than I thought?

Don't worry about the milestone change. This is still on my radar. -pn

*** Bug 7831 has been marked as a duplicate of this bug. ***

bu 8415 depends on this. addin myself to cc

telnet://shiver is running FreeBSD 2.2.7-STABLE

If you guys need an account on a FreeBSD-3.2 box to work on, mail me. I don't know how much resources you need -- I don't own a supercomputer :)

adding green@unixhelp.org who reported bug 7831 (a duplicate of this) and toshok, who says he was recently able to display png with his "freebsd 3.2-RELEASE" build. Could the rest of you freebsd people rebuild and verify you still have the problem? Also report your os version and whether you have libpng and libjpg installed. If so, which version.

And whether you are linking with moz png and jpeg libs or your native png and jpeg libs..... -pn

buid# 1999062312 on FreeBSD 3.1 release I now have the path to the png image displayed instead of the one pixel dot. Jpegs are still displayed as a one pixel dot.

I just tried the M7 release built with egcs 1.1.2 on FreeBSD 3.2-RELEASE, and the problem's still there. Using and linking with the system installed libpng 1.0.2 and libjpg 6b. I'll try last night's last-known-good build next.

I'm still seeing the problem with the July 2 tree. PNGs now display their alt text instead of loading; JPEGs still display as a single dot. Same specs as my previous comment.

Would you try forcing the build to use your mozilla libraries instead of linking in your bsd native libs? You will have to check autoconf, but I believe the option is configure --with-png. I have heard of several people having trouble with png and jpeg libs on bsd...but I have also heard of people on bsd having no trouble with png and jpeg decoders. When the image is displayed as a one pixel image, the decoder is not linked properly with the jpeg or png library. -pn

I configured with "./configure --with-png=no --with-jpeg=no", which from configure.in seems to be how you do that. libnspng.so and libnsjpg now have the symbols in them, but the problem is still there, same as it was.

Maybe someone should enquire on a FreeBSD list. I'm sure someone there will be interested in getting Mozilla to work on their OS.

Adding HELP WANTED notice. Mozilla should work with either the jpg and png libraries that come with the mozilla tree or with standard native libpng and libjpg that come with the system. Pam needs someone to build on BSD both with the mozilla libraries and with the native libraries. She suspects a problem with the build system. Perhaps configure is mis-detecting the presence of native libraries and links with the wrong thing.

the problem is with the build system because if my memory is correct before imglib landed we used to have jpegs. pete

Did some testing on some donated time on a bsd machine. Unfortunately, the theories with an easy fix don't appear to be the problem. Even if autoconf is set up to only use the mozilla jpeg and png libs (--without-png --without-jpeg ) the symptoms remain the same. Here is what you can tell from the symptoms: Instead of image, you see a single dot: the decoder wrapper is loaded, but something is wrong with the linkage to the format decoder. Perhaps the decoder lib is _bad_ for some reason, or the wrong decoder wrapper has been loaded. Instead of image, you see the text filename of the image: This is an error condition. The image file was not found, the decoder component was not found. This used to be a broken image icon but a decision was made to have the alt text or filename display instead. (not my decision, send differing opinions to the layout folks.).

OK, gang. We need a bsd wiz to track this down. I can't get gdb to run viewer. And if I can't use the debugger on viewer (or apprunner), I'm sunk. I created a build where I forced the jpeg component to link with the mozilla jpeg lib. I don't completely believe that autoconf is doing the right thing with the "--without-jpeg" switches. When I link and run viewer, I see the image file name displayed indicating an error that I could pinpoint, if the debugger would run. None of the other unixes seem to be having this problem. Any volunteers?

If this is a build problem, the problem is more than likely occurring in the compiler flags or link flags used for FreeBSD. As Pam stated, none of the other unices seem to have this problem and those flags are usually the biggest difference between platforms. I checked configure and the behavior of --without-jpeg seems to be correct. When --with-jpeg=no or --without-jpeg is used, SYSTEM_JPEG is unset which also causes MOZ_NATIVE_JPEG to be unset in config/autoconf.mk. This causes Mozilla to use the hardcode JPEG_CFLAGS & JPEG_LIBS set in config/autoconf.mk. PNG uses pretty much the same method. Everything looks fine except that JPEG_CFLAGS is set to -I$(DIST)/public/jpeg. We switched from using the public dir a while ago but this shouldn't affect anything as $(DIST)/include is in our default include path. Erk, scratch that..we still have this year old problem that we are testing for MOZPNG=95 when we should have version 1.0.2 or so in the tree. That should only cause a problem if the user's version of png is less than 1.0.2 but higher than 0.95 and we use features/behavior that is dependent upon 1.0.2. In any case, this should've been bumped long ago. I'm bumping it now. But according to these reports the problem occurs regardless of which libjpeg or libpng is used.

well i gues someone fixed jpegs. i have a fresh build and can view jpegs with viewer. aprunner hangs upon startup so i can't validate it there. pete

Pete tells me he is seeing pngs and jpeg with the most current build. (M9). The problem was fixed by dp's COM changes. Apparently, there was a problem with component loading just for bsd. I have not yet heard if chris has made changes in autoconf to update the png version test. -pn

[e-mailed pinged lennox@cs.columbia.edu to request confirmation that it's fully fixed, as we don't have a FreeBSD system around.]

[lennox@cs.columbia.edu confirms that it works for him, too. Thus, rubber- stamping as Verified Fixed.]

pam, just a note about verify png's. when i first try to view a png in viewer. It does not display. I get the old address of the image. Then viewer crashes. when i restart and view the same png URL - i can now see it. So there is still a lurker in there somewhere. pete

p.s. after the png loads i get an Assertion: Assertion: "mForegroundCount messed up" (mForegroundCount > 0) at file nsLoadGroup.cpp, line 459 pete

I'll have to pull this morning's tree, but I think this was identified and fixed over the weekend. It happens on all platforms. -pn

Uh-oh.. I'm going to re-open this one again. Everything seemed fine, except .jpg's aren't displayed anymore -- they are routed through the .png decoder, which (correctly) claims that what it gets isn't a .png! Oops... .PNG seem to work nicely though. This happened _after_ the merge of the m9 tree into the nightly builds. Before that merge, .JPG's displayed correctly, but .PNG's didnt. I've only tested this on today's source code... Correct me if this is just an insane hallucination or a regression in today's code.

[clearing resolution]

Has anyone else seen problems with image decoders loading since m9? The problem described with the reopening of this bug may be caused by not clobbering the build after updating. Let me know if you are still seeing a problem after you have tried rebuilding after doing a 'clobber all'.

Hellllllloooooo? Are the components loading or not loading? Need your input.... -pn

We were having some problems with Perl due to some changes to the rtld-elf code on FreeBSD-4.0-CURRENT (which is our only available build platform right now) These problems have just been fixed .. so I am building Mozilla right now to find out the current status on the component loading. Pascal (daeron@shadowmere.student.utwente.nl) Theo (havoc@phoenix.student.utwente.nl)

Ok ... my most recent build shows no problems at all using PNGs and/or JPEGs on a FreeBSD-4.0-CURRENT system ... I think we can close down the bug as fixed. Build ID: 1999082316

marking fixed per daeron's comment.

Okay, I've tried this on FreeBSD-3.2 -- Friday's last-known-good tree (09/03/1999 14:59:32 PDT), compiled with egcs 1.1.2, and I'm still having problems, so I've reopened this bug. Here's what I'm seeing: I can view either PNGs *or* JPGs, but once I've viewed one of them, it becomes impossible to view the other. (If I view a PNG first, JPGs show up as a single dot; if I view a JPG first, PNGs show up as their ALT tags.) It looks like both PNGs and JPGs are getting routed to whichever component got loaded first. If a PNG got loaded first, trying to view a JPG will result in "nspng libpng error: Not a PNG file" being printed on the debug output. libjpeg isn't as chatty, apparently... I configured with --without-png --without-jpg so the build wouldn't try to use my system versions of libpng and libjpg, but would instead build its own. Symptoms when I used the system libraries were somewhat similar, but I hadn't completely figured out the nature of the problem yet so I can't say for sure. Note: I only tried this on viewer, since bug 13154 prevented me from running apprunner. I'm using resource:/res/samples/test2.html for my sample JPEG (the dinosaur), and http://www.cdrom.com/pub/png/ and descendant pages for sample PNGs.

The only difference I can find between the "Broken FreeBSD" and the "Working FreeBSD" builds ... are the facts that the working builds are created on my 4.0-CURRENT system using system png and jpeg libraries, instead of Mozilla's own versions. I checked again with code just updated (--clobber) and I do not have problems with either JPG or PNG images no matter in what order the images are loaded. PNG/JPEG/PNG works just fine as well as JPEG/PNG/JPEG. I guess this is a 3.x-only bug then.

From lennox's comments, it sounds like the components are loading ok, but not unloading. I'm reassigning to dp, since he may have insight on problems related to component unloading. -pn

Toshok can you help us with this ?

Yep, i can confirm. You can either view jpeg or png. Not both in the same session. This is only for viewer since freeBSD hasn't been able to run apprunner for almost two weeks now. Perpetual browness! pete

Okay, a new discovery: --enable-low-fat (which strips symbols out of component libraries) works around this problem, and a huge number of other ones, on FreeBSD. It causes its own problems, though, namely spewing "Ignored d_tag " messages to stdout...I'll try to track this one down and file it as a separate bug report.

Okay, I've got a fix for this problem -- but I don't believe it's really fixing the root cause. The problem is coming about because both libnspng.so and libnsjpg.so define a global symbol "gFactory". Because of FreeBSD's "pick the first symbol" bug (discussed in bug 13154), we're seeing the behavior described. The patch I've attached (to declare gFactory as static) fixes the problem in this case, and is fine from a code-cleanliness point of view anyway, but doesn't get at the root cause of the problem. There's enough copy&pasted code in Mozilla that trying to find every multiply-declared symbol and declare it static is certainly an impossible task...

Pam can you take care of applying the patch in imglib to get freebsd working again.

sure. no problem. -pn

I just checked in the 2 changes but I'm not marking this as fixed. Only you BSD folk can decide if this is fixed or not. Thanks, lennox! -pn

m10 buyg list cleanup.-> m11

Reassigning to toshok@hungry.com; toshok@netscape.com is no longer valid.

can some one on freebsd check this out?

I can confirm jpg's and png's work on a build from yesterday on viewer only. apprunner is not working on freeBSD yet. pete

sounds like we can mark this one fixed and verify on on ./mozilla when it appears on free bsd.

I agree i believe this one is fixed. I have been working to try to track down a new bug on FreeBSD that has to do with unicode and CSS paths. The converter stream is busted. I am not filing this as a bug because I know freeBSD is not being supported. Lennox -- Is apprunner working for you?? any help would be an awsome thing! pete

[Pinged lennox@cs.columbia.edu for his $.02. Will rubber-stamp as Verified/FIXED by end of week if nobody is seeing this.]

It's the end of week...do you know where your FreeBSD users who aren't seeing PNGs and JPEGs are? ;) But, seriously, verifying as fixed by virtue of lack of protest. If anyone is still seeing this issue on a current build, please re-open with your comments. Thanks!

I think you can close this one. I would love to verify this for you but i can't. All FreeBSD versions accept for 4.0 Current are failing to run apprunner and viewer. See: http://bugzilla.mozilla.org/show_bug.cgi?id=20857 pete

depends on 20857, FreeBSD needs to startup properly.