202146 - Browser cannot start - iconv_open not found

Status: VERIFIED DUPLICATE of bug 205360

(Core :: Internationalization, defect)

Description

[beanladen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Solaris 8; en-US; rv:1.4a) Gecko/20030401

Sparc Solaris 8 1.4a Mozilla build (not Sun contributed!) does not
start.

Reproducible: Always

Steps to Reproduce:
1.start mozilla
2.
3.

Actual Results:  
ld.so.1: ./mozilla-bin: fatal: relocation error: file ./libxpcom.so: symbol
iconv_open: referenced symbol not found


Expected Results:  
Start !

This may be related to the activities in bug 147333. It seems that the 
availability of libiconv.so is tested while building on the build machine,
which is a really bad idea. Nobody can guarantee that others have this 
configuration. On our machine is no libiconv available.
locale gives LANG=C, LC_CTYPE=iso_8859_1.
Solaris 7 1.4a build from the same build source works.

Comment 1

[Roland Mainz]

Do you have all the Solaris Recommended&Security patches applied to your machine
?

Comment 2

[beanladen]

Please avoid 'automatic' comments. We all know that this has to do with
the missing libiconv.so and the build config assuming that it is there.

Comment 3

[Roland Mainz]

beanlade wrote:
> Please avoid 'automatic' comments. We all know that this has to do with
> the missing libiconv.so and the build config assuming that it is there.

The build config not the problem. A fully patched system working has that
library and we can't really support all incarnations of systems which lack
patches which are out since months.

Comment 4

[Roland Mainz]

s/patched system working has/patched system provides/

Comment 5

[beanladen]

Always the same wrong attitude as in several bugs dealing with SUN :-<
Please don't assume the latest bleeding edge patches and libraries
on a system. 
As a professional software developer, I can only say it again and 
again and again: Almost nobody has the very latest patches 
applied, and a couple of people are even not able to patch their
systems due to constraints by either: commercial software which breaks
then, or unwilling administrators, because the systems are large (>100),
and every patch also bears a risk (as we have seen already a couple of
times with Sun patches: You simply don't know what you are talking about,
we have been burned a dozen of times by patching !).
The only way to get any significant amount of people to use Mozilla 
on a platform is to assume the default installation, regardless how
difficult it is to get that working. Otherwise this software will
simply marginalize itself.
We are trying to move to Mozilla, but since those rules are always 
violated on this platform, we must give up this attempt now.
HOW EASY was it to run  Mozilla on Solaris before 1.3 !!

Comment 6

[beanladen]

QA: Requesting comment on the current direction the builds for Solaris platforms
    are heading now. That seems to constantly break the declared platform - 
    independence of Mozilla since ~1.3a . Steering activities may be advisable
    to keep the good reputations Mozilla had.

Comment 7

[Yuying Long]

There is no such sun system here, all we have are linux systems.  I already cc a
Sun person to aware this.

Comment 8

[Roland Mainz]

We can't rely on a broken system. Not applying at least the Recommended&Security
patch cluster is a gurantee that sooner or later something in Mozilla will not
work as expected.
For example when we miss the libCstd patches all hell breaks loose and we can't
really work around such problems within Mozilla code.
Same issue applies likely to the libiconv.so issue...

Nominating as WONTFIX.

Comment 9

[beanladen]

So why then the 2.7 build starts on 2.8 without requiring the libiconv ?
Is that build missing the essential features provided by libiconv (I never
noticed that anything is missing) ? So, if that build works, the simple fix
for the 2.8 build would obviously be to use the same config parameters.
If even only a few guys need the libiconv features, then it's really not
worth to block Mozilla usage for the overwhelming majority on Solaris.
A second build with iconv enabled for those guys would be the most simple
workaround.

Comment 10

[Renaud Manus]

Roland,

Unfortunately, this issue has nothing to do w/ the Solaris Distribution
or the recommended patches.

Mozilla has been compiled using the GNU library libiconv which is not
released w/ Solaris.

The fix is to install the libiconv library available at 

http://www.sunfreeware.com

--
Renaud

Comment 11

[Roland Mainz]

Renaud Manus wrote:
> Unfortunately, this issue has nothing to do w/ the Solaris Distribution
> or the recommended patches.
>
> Mozilla has been compiled using the GNU library libiconv which is not
> released w/ Solaris.

OK... maybe we need some carification here:
We have multiple contributors which build Mozilla - so we have to make sure
which build we're talking about.
Can we get the exact URL of the build which does not work, please ?

IMHO my builds nor dcran's Solaris builds depend on any GNU library (beyond
GDK/GTK+/IDL libs), they are compiled on clean, seperate build machines
(installed from the "full install+OEM support" package cluster).

Comment 12

[beanladen]

Build is (this NOT the forte build, as mentioned in the initial report):
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4a/mozilla-sparc-sun-solaris2.8-1.4a.tar.gz

Comment 13

[beanladen]

Duplicating to #205360, as patching activities are running there.

*** This bug has been marked as a duplicate of 205360 ***

Comment 14

[Yuying Long]

Mark as verified as dup.  Please re-open if disagree.