Closed Bug 205360 Opened 21 years ago Closed 21 years ago

libxpcom.so depends on non-existent libiconv.so

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Platform:
Sun
Solaris
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.4final

People

(Reporter: steven, Assigned: darin.moz)

References

Details

(Keywords: fixed1.4, regression)

Attachments

(2 files, 1 obsolete file)

v1.1 patch
738 bytes, patch
netscape
: review+
bryner
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review
v2.0
608 bytes, patch
dbaron
: review+
darin.moz
: superreview+
leaf
: approval1.4+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4a) Gecko/20030404
Build Identifier: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4b/mozilla-sparc-sun-solaris2.8_1.4b.tar.gz

The Solaris 8 build of 1.4b depends on libiconv.so, which does not (normally)
exist on Solaris.  Only the Gtk+ libraries are mentioned in the README, and 1.4a
does not have this dependency.

1.4a:
[/local]0$ LD_LIBRARY_PATH=mozilla-1.4a:/local/netscape-7.0/dist/lib ldd
mozilla-1.4a/libxpcom.so
        libplds4.so =>   mozilla-1.4a/libplds4.so
        libplc4.so =>    mozilla-1.4a/libplc4.so
        libnspr4.so =>   mozilla-1.4a/libnspr4.so
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /raid1/local/mozilla-1.4a/cpu/sparcv8plus/libnspr_flt4.so
        /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1

1.4b:
[/local]0$ LD_LIBRARY_PATH=mozilla-1.4b:/local/netscape-7.0/dist/lib ldd
mozilla-1.4b/libxpcom.so
        libplds4.so =>   mozilla-1.4b/libplds4.so
        libplc4.so =>    mozilla-1.4b/libplc4.so
        libnspr4.so =>   mozilla-1.4b/libnspr4.so
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
***     libiconv.so =>   (file not found)
        libc.so.1 =>     /usr/lib/libc.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /raid1/local/mozilla-1.4b/cpu/sparcv8plus/libnspr_flt4.so
        /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1



Reproducible: Always

Steps to Reproduce:
The very same problem exists also for 1.3.1 and all the Solaris 8 builds (The
Sun contibuted and the ones that have SVG anc CTL enabled).

Reporter:
1. Can you do a % nm /usr/lib/libc.so.1 | fgrep iconv_open # on your box to see
whether your version of libc.so.1 provides the symbol "iconv_open".
2. Can you install Solaris 2.8 patch "108993-18" and check whether that fixes
the problem (please try [1] after patching)
OS: SunOS → Solaris
*** Bug 205298 has been marked as a duplicate of this bug. ***
Comment to comment #2

<ogre:~> nm /usr/lib/libc.so.1 | grep iconv_open 
00040628 T _iconv_open
00040628 W iconv_open
000409f8 t iconv_open_all
00040b8c t iconv_open_private

<ogre:~> patchadd -p | grep 108993-18
Patch: 108993-18 Obsoletes: 108827-40 108991-18 109322-09 109461-03 111641-01
109680-01 110589-02 111217-02 111177-06 111921-02 112022-02 110194-01 110390-02
111090-03 111431-01 110700-01 111081-01 111464-01 111780-01 111085-02 111299-04
111393-02 111659-07 112218-01 112605-04 Requires: 108528-13 108989-01 110386-01
111023-02   Incompatibles: 109079-01 Packages: SUNWapppr SUNWapppu SUNWarc
SUNWarcx SUNWatfsr SUNWatfsu SUNWcarx SUNWcsl SUNWcslx SUNWcsr SUNWcstl
SUNWcstlx SUNWcsu SUNWcsxu SUNWdpl SUNWdplx SUNWhea SUNWlldap SUNWmdb SUNWmdbx
SUNWnisu SUNWpppd SUNWpppdr SUNWpppdu SUNWpppdx

And I have still the same problem that the original reported have reported.
Does it start when you run Mozilla like this:
% (LD_PRELOAD=/usr/lib/libc.so ./mozilla) # ?
Unfortunately not:

<ogre:/share/sparc-sun-solaris2.8/pub/mozilla/1.4b> setenv LD_PRELOAD
/usr/lib/libc.so 
<ogre:/share/sparc-sun-solaris2.8/pub/mozilla/1.4b> ./mozilla
ld.so.1: ./mozilla-bin: fatal: relocation error: file ./libxpcom.so: symbol
iconv_open: referenced symbol not found
Killed

Theory that I have not checked by anyway:

I would guess that the problem is in the original build. The source of the
problem may even be in the configure-script that for some reason thinks that
there is no iconv_open in the Solaris libc and thus makes such a configuration
that external libiconv library is used in libxpcom.so. Now the persons who have
made the builds have happened to have (Gnu?) libiconv in their include/lib
search paths and thus this kind of binding. Because there then is requirement
for the library named libiconv.so it is not possible to run the current builds
without that library.

I hope that some-one would conform if my theory is right or wrong. Anyhow it
seems to me that new builds for Solaris are required.
#6,s/conform/confirm/g
Exact same issue on Solaris 5.9 

sionnach(5.9)mozilla$ nm /usr/lib/libc.so.1 | fgrep iconv_open 
[4142]  |    266960|     180|FUNC |GLOB |0    |9      |_iconv_open
[4528]  |    266960|     180|FUNC |WEAK |0    |9      |iconv_open
[1167]  |    267876|     200|FUNC |LOCL |0    |9      |iconv_open_all
[1171]  |    268276|     360|FUNC |LOCL |0    |9      |iconv_open_private

% (LD_PRELOAD=/usr/lib/libc.so ./mozilla) # ?
does not help

I do not have a libiconv.so anywhere on my system.
Albert White wrote:
> I do not have a libiconv.so anywhere on my system.

Mhhh, do you have the "SUNWhuccd" package installed ?

Per
-- snip --
% cat /var/sadm/install/contents | fgrep libiconv.so
/usr/lib/libiconv.so f none 0755 bin bin 23348 20350 941709164 SUNWhuccd
% pkginfo SUNWhuccd
ALE         SUNWhuccd      Traditional Chinese User Based Chinese Console
Display Package
-- snip --
/usr/lib/libiconv.so sits in "SUNWhuccd"... ;-/

The question is: Why?
That library likely belongs into the Solaris core package cluster and not into
something like SUNWhuccd ...
Albert White:
Can you test whether installing the "SUNWhuccd" package fixes the problem,
please ?
There is no SUNWhuccd in Solaris 9, in fact I cant find libiconv.so in any
Solaris 9 package. However copying that file from the Solaris 8 package seems to
have done the trick.

A colleague has verified that using libiconv.so from his gnome distribution also
solves the problem.
I've talked to katakai on IRC, he said that the libiconv.so library shipped with
Solaris 2.8 was a private interface which was obsoleted later.

Looking at configure.in I see the change from bug 147333 which seems to assume
that the iconv library functions are only in libiconv.so:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=configure.in&branch=&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&rev1=1.1043&rev2=1.1044

The configure.in code needs to be adjusted to check whether libc.so provides the
iconv functions (Solaris - and likely other versions of Unix) or whether we have
to look for libiconv.so (Linux).

Over to darin - this seems to be a regression from bug 147333 ... ;-(
Assignee: general → darin
Flags: blocking1.4?
Keywords: regression
Marking bug as confirmed per user comments...
Status: UNCONFIRMED → NEW
Component: Browser-General → Internationalization
Ever confirmed: true
Flags: blocking1.4? → blocking1.4+
Sorry, removed wrong person :-P
i can try creating a patch, but i will need someone to test it.  any volunteers?
 (i don't have a solaris box.)
Severity: normal → major
Priority: -- → P3
Target Milestone: --- → mozilla1.4final
Yes, I can try if patch is available.
I can try it, too (I have exactly the kind of system configuration which
triggers the issue... ;-(( ) ...
darin:
A possible solution for this bug is described in comment #12 - basically you
only have to add a check before the "is-libiconv.so-available"-test whether the
iconv_*-functions are available in libc.so. If this condition is "true" you
behave exactly like having libiconv.so around but obmit "-liconv", e.g. do not
link against libiconv.
In theory this issue should go away then...
hmm... so is linkage to libiconv required on some solaris versions and not
others?  does libc always provide iconv_ functions on solaris (even when
libiconv is present)?
seawood: this is related to the configure.in changes we made for bug 147333. 
i'm going to try my luck at whipping up a patch, but i just wanted to know if
you have any thoughts on comment #19 and related comments.  thx!
Status: NEW → ASSIGNED
Darin Fisher wrote:
> hmm... so is linkage to libiconv required on some solaris versions and not
> others? 

Nah... - just grab the functions from libc.so, please.
The libiconv.so provided by "SUNWhuccd" is - as far as I have understand the
issue - a (semi-)private interface (however if that is true it should never have
been put into /usr/lib/ at all since that triggers bugs like this one -
hopefully a OS patch fixes that issue).

> does libc always provide iconv_ functions on solaris (even when
> libiconv is present)?

At least on Solaris 2.7/2.8/2.9 libc.so seems to provide the iconv_*-functions,
so I guess the answer is "yes".
I can't say it for Solaris 2.6 - but that OS version is AFAIK now obsolete... :)

BTW: I suggest not to hardcode this stuff for Solaris - I guess other Unix
vendors may behave the same way as Solaris does (maybe even later Linux glibc
versions clone that behaviour... :)
Solaris 2.6 also provides the iconv_* functions in /usr/lib/libc.so:


# uname -a
SunOS agusta 5.6 Generic_105181-34 sun4u sparc SUNW,Ultra-4

# nm /usr/lib/libc.so |grep iconv
[4428]  |    286276|     180|FUNC |GLOB |0    |12     |_iconv
[3137]  |    286144|     132|FUNC |GLOB |0    |12     |_iconv_close
[3865]  |    285624|     220|FUNC |GLOB |0    |12     |_iconv_open
[4084]  |    286276|     180|FUNC |WEAK |0    |12     |iconv
[1395]  |         0|       0|FILE |LOCL |0    |ABS    |iconv.c
[4209]  |    286144|     132|FUNC |WEAK |0    |12     |iconv_close
[2725]  |    285624|     220|FUNC |WEAK |0    |12     |iconv_open
[1404]  |    285844|     300|FUNC |LOCL |0    |12     |iconv_open_private
Attached patch v1 patch (obsolete) — — Splinter Review 
this configure.in patch should do the trick.  (incidentally, i'm not sure why
we have a check to look for libiconv in -liconv.  that seems bogus, but maybe
it is needed for some obscure platform.)
folks: please give the v1 patch a try, and let me know if it works for you.  thx!
Could anyone tell me how to make configure from configure.in?
Comment on attachment 123293 [details] [diff] [review]
v1 patch

You should probably explicitly add -lc to _ICONV_LIBS so that -lc is only
explicitly linked against libxpcom.
*** Bug 202146 has been marked as a duplicate of this bug. ***
Christopher Seawood wrote:
> (From update of attachment 123293 [details] [diff] [review])
> You should probably explicitly add -lc to _ICONV_LIBS so that -lc is only
> explicitly linked against libxpcom.

Correct me if I am wrong, but doesn't the compiler always add "-lc"
automatically at the end when linking ?
It depends upon the compiler.  It's a fringe case but my mipsEEel-linux
cross-compiler doesn't explicitly link against -lc.  I had to set LIBS=-lc
before compiling.  You're also assuming that you're always using the compiler to
link (as opposed to calling the linker directly).

Christopher Seawood wrote:
> It depends upon the compiler.  It's a fringe case but my mipsEEel-linux
> cross-compiler doesn't explicitly link against -lc.  I had to set LIBS=-lc
> before compiling.

I guess this is a rare behaviour (maybe because it's a cross-compiler ?!) since
Sun, Cray, NEC and AIX compilers link against -lc by default (but I don't know
how gcc behavaves), right ? :)

> You're also assuming that you're always using the compiler 
> to link (as opposed to calling the linker directly).

OKOK, point for you... :))
Attached patch v1.1 patch — — Splinter Review 
adds -lc to _ICONV_LIBS
Attachment #123293 - Attachment is obsolete: true
Attachment #123982 - Flags: review?(seawood)
Wow, I wasted a lot of time with the official (tested?) 1.3.1 before finding
this 'severe bug in a final release' bug report.  :(

People pick up non-alpha/beta releases because they, in theory, get you at
least as far as a window opened.

So instead of just complaining (because we know that's not allowed when
dealing with free software), here's what would have made dealing with
this situation more tolerable: Do some sort of dump of 'severe' bugs in
final releases into pub/mozilla/releases/release-version/BUGS every night.

An errata file (or having the useless/broken .tar.gz files pulled with a
note!) would be very useful.  And I know, right now, someone reading this
is screaming, "The bugs are already in the database for you to query!" and
is missing the whole point.

Just an idea -- sorry if you think I'm a jerk.

jblaine,
A Customer of the Product
Attachment #123982 - Flags: review?(seawood) → review+
Attachment #123982 - Flags: superreview?(bryner)
Attachment #123982 - Flags: superreview?(bryner) → superreview+
Comment on attachment 123982 [details] [diff] [review]
v1.1 patch

seeking drivers approval for this trivial patch to fix a crippling solaris
build issue ;-)
Attachment #123982 - Flags: approval1.4?
Darin Fisher wrote:
> (From update of attachment 123982 [details] [diff] [review])
> seeking drivers approval for this trivial patch to fix a crippling solaris
> build issue ;-)

This is likely not a Solaris-only issue, this problem applies to all OSes which
stick the iconv_*-functions into libc.so instead of having a seperate
libiconv.so

Offtopic:
My 2.8 build box is down, I can't test the patch until saturday (spareparts come
likely tomorrow but I need some free time to dismantle the box) ...
Comment on attachment 123982 [details] [diff] [review]
v1.1 patch

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #123982 - Flags: approval1.4? → approval1.4+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Jeff Blaine,
I'm sorry for wasting your time on testing... For my understanding, this build
on mozilla.org is for individual users. If you want to find a stable version on
Solaris, you probably need to download it from Sun website. We release netscape
and mozilla.
I did do some testing after build it. But I'm not a QA and I don't have much
resources to do it on different env. Really sorry for this, but I will try my
best to test it after build it in the future.
Anyway, I will upload a new build soon.

Thanks
Pete
*** Bug 207989 has been marked as a duplicate of this bug. ***
This patch (the addition of explicitly linking against "-lc") broke a build that
I was just doing.  (The build was an experiment in distributable Linux builds --
an RH 6.2 box with all errata, GNU make 3.79.1, binutils 2.13.2.1, and a gcc
3.2.3 compiled with "--enable-languages=c++ --enable-__cxa_atexit
--disable-shared --disable-checking --enable-threads=posix --with-system-zlib".)

It *only* caused an error when linking libxpcom.so, and the error I got was:

/usr/local/bin/ld: libxpcom.so: undefined versioned symbol name
__register_frame_info@@GLIBC_2.0
/usr/local/bin/ld: failed to set dynamic section sizes: Bad value

(after manually linking libxpcom.so without -lc, the rest of the build ran fine).

So do we really want the -lc in there?
Attached patch v2.0 — — Splinter Review 
Ok, I was wrong.  We shouldn't be explicitly linking against -lc.  However, you
have to put something in the ACTION-IF-FOUND case of AC_CHECK_LIB or it will
automatically add that library to LIBS.
Comment on attachment 125546 [details] [diff] [review]
v2.0

r=dbaron, although does using AC_CHECK_FUNC make sense?  (I'm not sure.)
Attachment #125546 - Flags: review+
Comment on attachment 125546 [details] [diff] [review]
v2.0

AC_CHECK_FUNC only checks  for the function in the libs in LIBS so you'd have
to call AC_CHECK_LIB anyway or temporarily add -liconv to LIBS to test for
iconv().
Attachment #125546 - Flags: approval1.4?
reopening.  this is breaking our attempts to build linux on gcc 3.2.3.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 125546 [details] [diff] [review]
v2.0

sr=darin
Attachment #125546 - Flags: superreview+
Blocks: 204236
Comment on attachment 125546 [details] [diff] [review]
v2.0

need this for static linking builds on 7.3
Attachment #125546 - Flags: approval1.4? → approval1.4+
checked in to trunk and branch.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Keywords: fixed1.4
Resolution: --- → FIXED
*** Bug 206849 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: