156774 - Installer failed to clean out old uconv resulting in startup failure looking for AppendFromReadable in uconv

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect)

Description

[Akkana Peck]

Today's commercial build from sweetlou (I haven't tried a mozilla build, but
I've tried both blob and net installer builds) fail to start up:

/usr/local/netscape/netscape-bin: relocation error:
/usr/local/netscape/components/libuconv-1.so: undefined symbol:
AppendFromReadable__9nsAStringRC9nsAString

Comment 1

[Akkana Peck]

Adding smoketest keyword, since starting up is surely part of the smoketests.

I tried moving my .mozilla aside in case it was a profile issue, but it still fails.

Comment 2

[Akkana Peck]

Alecf found the clue: the installer isn't removing old libraries, so an old
obsolete version of uconv from a previous build is registering itself and
causing problems.  (I rm -rf netscape-installer before I extract the tar, but I
don't remove the files in /usr/local/netscape because the installer has always
done that for me.)

Over to installer.

Comment 3

[kinmoz]

Is installing over a previous installation part of the smoketests? I'm just
wondering if this should be downgraded from smoketest blocker if we have a
handle on the issue that is causing this problem.

Comment 4

[Akkana Peck]

Kin persuaded me that this doesn't need to block other checkins -- the problem
is probably fairly localized.  But it really does need to get fixed before we
ship, since it means the app won't work for anyone who uses the installer to
upgrade.

Comment 5

[Daniel Veditz [:dveditz]]

"ship"? is this a branch bug, or do you mean the next mozilla trunk milestone?

We don't normally install libuconv-1.so, that's looks like the format for temp
names we use. why wouldn't it have been able to zap your old libuconv.so? Is it
possible you were running that copy of Netscape while installing? Is there some
path variable that might have caused a running Mozilla build to grab the
libraries in that directory?

Please check the timestamps in your component directory and report any that
appear to be "old".

Comment 6

[Akkana Peck]

libuconv-1.so in the older installation is dated May 9.  I'm fairly sure it was
a branch build.  I was not running it while installing -- I always quit the
current one before installing a new one.  (Of course, it's possible that the
window disappeared but the process was still running; I didn't do a ps to make
sure.)  I tried several times -- the problem was quite repeatable.

In case anyone cares, today's commercial trunk net installer doesn't work either
-- it fails trying to download talkback, retries about three times, then fails
with a CRC error (and the usual hundreds of lines of GTK-CRITICAL messages about
the percent-done being wrong).  That too was repeatable.  Removing talkback.xpi
and then rerunning the installer with talkback deselected finally got me going.

Comment 7

[Akkana Peck]

With today's build I'm again seeing the installer fail to remove old files
before installing (doesn't ask about whether to remove them, either); the
failure mode this time is that the profile manager dialog comes up unskinned
with some serif text but sized very wide and only a few text lines high, so no
profiles or buttons are visible.

Comment 8

[timeless]

libuconv-1.so isn't in browser.jst but all of: ucvja, ucvko, ucvcn, ucvlatin,
ucvtw, ucvtw2, ucvibm,
 are... 

Comment 9

[Alec Flett]

libuconv-1.so is a temporary file, its used to overwrite libuconv.so.

its probably from an old installation or something, just delete it.

Comment 10

[Alexander Opitz]

Does this bug is a problem in newer builds?

Comment 11

[Alexander Opitz]

No reports or problems on this ... seems also an NS only problem so closing as WFM.

Comment 12

[timeless]

erm. this is silly. resummarizing. the bug is in the installer and could happen
if you pick an old enough mozilla as a victim and a new enough mozilla as a
candidate.

don't kill bugs just because the transition required to experience them isn't
frequently triggered.

Comment 13

[Daniel Veditz [:dveditz]]

We can go ahead and close this one. We've never reproduced the fluke that left
the  temporary file behind, but xpinstall should no longer create temp files
with names that XPCOM will try to use as valid components.