On Tue, Aug 01, 2006 at 02:57:45PM +0200, Pier Luigi Pau <[EMAIL PROTECTED]> wrote: > Package: firefox > Version: 1.5.dfsg+1.5.0.5-1 > Followup-For: Bug #378667 > > The failure of the HTML Validator extension as reported in this bug may > be due to the changes in LDFLAGS introduced with 1.5.dfsg+1.5.0.4-2. > > See item 3 of the extension FAQ at > > http://users.skynet.be/mgueury/mozilla/faq.html > > which, though focused on missing libstdc++5, basically suggests that > the extension may be trying to find libnspr4.so, libplds4.so, > libplc4.so in the firefox binary only. > > Creating symbolic links to libnspr4.so.0d as libnspr4.so, etc. doesn't > seem to help; neither does installing the libnspr4 package. Symptoms > remain the same: the page at > > http://users.skynet.be/mgueury/mozilla/no_tidy_lib.html > > is displayed. Perhaps, yes, this should be reported upstream. > > HTML Validator does work with the firefox binary distribution downloaded > from mozilla.com. > > I haven't tried compiling the extension from source (yet).
Indeed, there are 2 colliding problems. First, the changes in LDFLAGS introduced in 1.5.dfsg+1.5.0.4-2 made libxpcom.so not loaded at runtime. It is linked by none of the binaries or components. The components provided by firefox are linked against libxpcom_core.so. Most native components you'll find in the wild will be linked that way. BUT, this tidy extension, as the "simple" example component in mozilla tree, is statically linked to the xpcom glue, which is the dumbest thing they've ever done, and causes the problem. I'd suggest to tell the html validator author to change his Makefile.in to not use the xpcom glue. On the other hand, I need to see why libxpcom.so is unused... I still need to talk to more mozilla guys about this xpcom glue nonsense... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
