283760 - firefox-installer with libsafe fails: "DLError: /libxpistub.so: cannot open shared object file: No such file or directory"

Status: RESOLVED INVALID

(Firefox :: Installer, defect)

Description

[Bob Niederman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

THis has been happening on my Redhat 9.0 for most of a year.  Every single time,
without exception, since well before MOZILLA 1.0, I have to track down some
stupid libxpistub.so and put it in /.

Why is the installaer looking in / for a lib?  Why doesn't the the installer put
it there?  At least the older installer broght on ealong, even if they were too
stupid to find it.  The latest version firefox-1.0.1.installer.tar.gz doesn;t
even have the the thing - I had to get it from a previous installer.



Reproducible: Always

Steps to Reproduce:
1. download insstaller tar.gz.
2. use installer
3. see error.  every time.

Actual Results:  
see above

Expected Results:  
I expect the program to install firegfox wihout having to copy semingly
unrelated stuff into /

Comment 1

[Simon Paquet [:sipaq]]

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

Comment 2

[Andrew Schultz]

not bug 246173

> Why is the installaer looking in / for a lib?

The most likely explanation is that the installer thinks it put the lib in /  :)

What do you have environment variables TMPDIR, TMP and TEMP?

Red Hat 9 should be sufficient for firefox.  It certainly was sufficient for
Mozilla 1.0

Comment 3

[Andrew Schultz]

bob wrote:
> 
> All 3 environmental variables are blank.
> 
> Do you know what should they be?

normally one of them would point to the directory where temporary files should
be placed.  If none are set, the installer should fall back and put them in
/tmp.  The installer should make a subdirectory under /tmp (like xpi.ABCDEF) and
put libxpistub.so in a "bin" subidrectory under that.

When the error dialog comes up, leave it open.  Look in the /tmp directory and
see if there is a xpi.XXXXXX directory there with appropriate files in it (once
you click ok, the directory gets deleted)

Comment 4

[Bob Niederman]

OK, it's there:

# ll /tmp/xpi.4eeH5y/bin/libxpistub.so -tr
-rwxr-xr-x    1 root     root         7736 Feb 26 12:52
/tmp/xpi.4eeH5y/bin/libxpistub.so


SO now I know wehre to get the right one in the future.  I sitll don;t see why
this is happennign.  I alwasy do this as root, so I have all the rights.  Is
this still realy a glibc issue?

Comment 5

[Andrew Schultz]

> I sitll don;t see why this is happennign.  I alwasy do this as root, so I have 
> all the rights.  Is this still realy a glibc issue?

You shouldn't need to be root. AFAIK, it has nothing to do with glibc.

Can you
1. download an installer build from 
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2005-03-03-06-trunk/
(try it, make sure you hit the same problem)

2. download http://mysite.verizon.net/ajschult/mozilla-installer-bin.bz2, and
use it to replace the original mozilla-installer-bin.  try running again.  it
should print out lots of stuff.  redirect it to a file, and attach the file to
this bug.

./mozilla-installer > logfile
you can just tell it to install to /tmp/mozilla or something and then delete it
(if it gets that far)

Comment 6

[Bob Niederman]

(sorry if this is a duplicate on the list).


The logging installer wasn;t much use - no logfile created:

[root@trc2:/root/tet_moz_bug/mozilla-installer]#  ./mozilla-installer >
logfile
./mozilla-installer-bin: error while loading shared libraries:
libstdc++.so.6: cannot open shared object file: No such file or directory
[root@trc2:/root/tet_moz_bug/mozilla-installer]# cat logfile
[root@trc2:/root/tet_moz_bug/mozilla-installer]#
[root@trc2:/root/tet_moz_bug/mozilla-installer]#

didn't get far enouugh to have the libxpistub problem.

Comment 7

[Andrew Schultz]

doh.  right.  so the binaries that .mozilla.org creates are somehow statically
linked against libstdc++.  Mine aren't and I have a newer version of libstdc++
than you, so it fails.

I'll try to get a debugging version built on a RH 9-ish machine.

Comment 8

[Andrew Schultz]

ok, same drill, this time with firefox:
http://mysite.verizon.net/ajschult/firefox-installer-bin.bz2
I built it from 1.0.1 sources, but it should probably work more recent builds as
well.

Comment 9

[Bob Niederman]

Attachment: log formdebugging installer, per request of [e-mail]

I was requested to post this to the bug by  [e-mail] - thanks to
all for the effort.

BTW, TMPDIR, TEMPDIR and TEMP are all unset on my RH9 machine.	Non-standard: 
I have "unset LANG" in all my shells as the en_us.UTF-whatever default setting
gave me problems with perl XML and man.

Comment 10

[Bob Niederman]

Note: restoring the LANG setting of en_US.UTF-8 did not changge the results. 
The log file is exactly the same except for:

47c47
< nsXIEngine.cpp 514: /tmp/xpi.t9JUiC/bin:. 
---
> nsXIEngine.cpp 514: /tmp/xpi.kj121k/bin:. 

Comment 11

[Andrew Schultz]

ok, the log helps narrow it down a bit more.  I put up a new firefox installer
(same URL) that should print out every step where it might be failing.

Comment 12

[Bob Niederman]

Attachment: another log file as requested by Andrew

another log file as requested by Andrew

Comment 13

[Andrew Schultz]

Bob: thanks!  Can you grab one more firefox installer from the URL and try it? 
I think I fixed it.  :)

http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/unix/src2/nsXIEngine.cpp#628
It sprintf's a string into itself.  That's kinda evil, but it's never caused a
problem before (that I know of) and that line has been there since the linux
installer existed.

Comment 14

[Bob Niederman]

That works.  Congratulations and thanks.  This is a credit to the developers
that this got solved so quickly once I took the time to open a bug.

BTW, I always had this problem with the mozilla installer, before I switched to
firefox.

Anyhow, thanks again.

Comment 15

[Andrew Schultz]

Attachment: patch

dveditz: can you r/sr the seamonkey part?

Comment 16

[Andrew Schultz]

bryner: can you r= the firefox patch

Comment 17

[Andrew Schultz]

Bob and I figured out that libsafe was the trigger.  See bug 59012 comment 5.
But the code in Mozilla is still evil.

Comment 18

[Carsten Book [:Tomcat]]

Since we no longer provide a Installer for Firefox Linux Builds, i close this bug as invalid.