8803 - Linux/Slackware: undefined iostream symbols, app won't start

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P1)

Description

[johnod]

johnny:~/mozilla/package# ./mozilla-apprunner.sh
MOZILLA_FIVE_HOME=/root/mozilla/package
  LD_LIBRARY_PATH=/root/mozilla/package:/usr/local/rvplayer5.0
      MOZ_PROGRAM=./apprunner
        moz_debug=0
     moz_debugger=
./apprunner: error in loading shared libraries
/root/mozilla/package/libraptorhtmlpars.so: undefined symbol:
__vt_8iostream.3ios

I am running Slackware 4.0 and never have had any luck running any
of these "milestone" releases.  This was the M7 attempt.
Just thought you should know.
Thanks
Johnny O

Comment 1

[leger]

What is Slackware 4.0?

Comment 2

[don]

Steve, do you know what the problem here could be?  Re-assign to the build team
if necessary ...

Comment 3

[Steve Lamm]

Slackware is a distribution of linux,

http://www.slackware.com/

Comment 4

[johnod]

> > + What is Slackware 4.0?
>
> Have you heard of Linux?  Slackware Linux?  The oldest distribution of Linux?
> Well, they are up to version 4.0 now with glibc2 runtime compatability, but
> still libc5 based.

Comment 5

[Akkana Peck]

This looks like the htmlparser library is relying on streams.  We know there are
stream incompatibilities between all the platforms we support, and my
understanding is that we were supposed to be moving to use nsStream everywhere
instead of iostream.  But when I search lxr for iostream.h, I still see a LOT of
files including it: http://lxr.mozilla.org/seamonkey/search?string=iostream.h
Cc'ing Rick (who owns the parser library and nsString2,), dp (for xpcom), tague
(for intl), and brendan and ramiro (because they might want to be aware of the
issue).

Comment 6

[Akkana Peck]

bugzilla threw away my cc line changes; trying to make them again.

Comment 7

[Chris Yeh]

so why is this bug assigned to leaf? re-assigning to rickg.

As discussed previously, the use of iostream kills a lot of the portability in
the product, and I thought the decision was to either use NSPR, or as akkana
mentions, using nsStream.

If we changed our minds, and this is the right thing to do, then make a note of
that and close the bug, but this is beyond leaf's scope.

Comment 8

[leger]

Setting component to Parser.

Comment 9

[Roland Mainz]

Bug 8413 may be a dup of this. Some Sun SPARC nightly builds (Solaris 2.5.1)
have the same problem; but when I compile them directly under Solaris 7 (+egcs),
the problem never occurs. Seems to be a build config related problem...

Comment 10

[rickg]

I'm about 1/2 way done with ripping iostreams out of the parsing engine. All
that's left is debug code, and I'll switch that over to JohnM stream classes
soon.

Comment 11

[chris hofmann]

moving the rest of this work to m9

Comment 12

[rickg]

Harish -- I'm giving this to you now, since all that's left is the debug methods
which use ostream.

Comment 13

[Chris McAfee]

resummarizing.

Comment 14

[harishd]

Moving to M10.

Comment 15

[harishd]

Replaced ostream with nsStream on all debug methods.
Marking bug fixed.

Comment 16

[Roland Mainz]

I build Milestone M9 without any problems on Solaris 7 sparc with gcc 2.95.1.
Seems to be fixed :-)

Thanks !

Comment 17

[Jan Carpenter]

Thanks!
Marking verified.