Cannot install Mozilla nightly build on Linux. "Fatal Error [-618]: Couldn't open xpistub library"

VERIFIED FIXED

Status

SeaMonkey
Installer
--
critical
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: Nisheeth Ranjan, Assigned: dveditz)

Tracking

Dependency tree / graph
Bug Flags:
blocking1.6b -
blocking1.6 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Ignore comment 21 through comment 45; see comment 37 for why])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607

Cannot install Mozilla nightly build on Linux.  Get the following error: "Fatal
Error [-618]: Couldn't open xpistub library".  See the steps to reproduce below...

Reproducible: Always

Steps to Reproduce:
1. Download nightly build
2. Run the mozilla installer
3. After going through the setup screens, you get the above error message when
the install starts to extract files from the xpi.  Always get the error message
while the message "Extracting libplc4.so..." appears on the install window.

Actual Results:  
Got an error message during install and the install did not complete.

Expected Results:  
The install should have completed without the error message.

If you do a Google search on "xpistub library", you will find a bunch of users
complaining about this problem.  Maybe there is some more information in those
reports.

Comment 1

16 years ago
you are probably seeing bug 59012.  do you have the libstdc++ compatibility
library (egcs++) installed?

Updated

16 years ago
QA Contact: bugzilla → ktrina

Comment 2

16 years ago
With egcs/egcs++ installed (compat-egcs-c++-6.2-1.1.2.16.i386.rpm, 
compat-egcs-6.2-1.1.2.16.i386.rpm, compat-egcs-g77-6.2-1.1.2.16.i386.rpm,
compat-egcs-objc-6.2-1.1.2.16.i386.rpm, compat-libstdc++-6.2-2.9.0.16.i386.rpm),
the same error still occurs. 

This isn't the version of libstdc++ recommended in <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=59012">bug 59012</a>'s
summary, and someone else there reported trouble with the same version of
libstdc++, but downgrading to compat-libstdc++6.2-2.9.0.9 broke too many
dependencies for me to try it.  Removing libsafe, as suggested <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=59012#c5">here</a>, made the
installer work, though. 

Comment 3

16 years ago
the same with version 1.2.1 on suse linux 8.1

Comment 4

16 years ago
the same with version 1.3a on suse linux 8.1

Comment 5

16 years ago
*** Bug 186998 has been marked as a duplicate of this bug. ***

Comment 6

16 years ago
I've tried to install mozilla 1.3 on my RH 7.2 desktop wich is up to date. Also
compat-libstdc++-6.2-2.9.0.16 is installes, but got the same error. After
installing nautilus-mozilla, and RH's mozilla 1.0.1 rpms the bug is stil there,
but with another error message:

[root@hades mozilla-installer]# ./mozilla-installer-bin
./mozilla-installer-bin: relocation error: /tmp/xpi.VXQwdA/bin/libxpistub.so:
undefined symbol:
CreateInstance__18nsComponentManagerRC4nsIDP11nsISupportsRC4nsIDPPv

libsafe is not installed

Comment 7

16 years ago
don't run mozilla-installer-bin.  run mozilla-installer

Comment 8

15 years ago
*** Bug 203471 has been marked as a duplicate of this bug. ***

Comment 9

15 years ago
I have this same problem installing Mozilla 1.4b on Redhat Linux 6.1.
I tried both the full installer as well as the net installer:

    mozilla-i686-pc-linux-gnu-1.4b-sea.tar.gz
    mozilla-i686-pc-linux-gnu-1.4b-installer.tar.gz

The installer quits with the error message:

    Fatal Error [-618]: Couldn't open xpistub library

At the time the error appears the message "extracting libplc4.so"
is shown above the progress bar in the installer dialog box.

Note: I've had no problems installing the following versions
on the same workstation:

    v1.0.1
    v1.1
    v1.2.1
    v1.3a
    v1.3b
    v1.3
    v1.4a

I haven't tried v1.3.1.

here's the info from about: on the version I'm currently running:

    Mozilla 1.4a
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Comment 10

15 years ago
*** Bug 204851 has been marked as a duplicate of this bug. ***

Comment 11

15 years ago
I get the same with 1.4b and 1.3.1 on RH 6.2.  

I didn't have this problem with Mozilla 1.4a or 1.3 

Comment 12

15 years ago
*** Bug 204988 has been marked as a duplicate of this bug. ***
Steve, Mozilla.org dropped support for RH 6.2.

Comment 14

15 years ago
Well Boris I don't know how one would deduce that from the release notes which
say in the system requirements section for Linux:

#  The following library versions (or compatible) are required: glibc 2.1,
XFree86 3.3.x, GTK 1.2.x, Glib 1.2.x, Libstdc++ 2.9.0. Red Hat Linux 6.0, Debian
2.1, and SuSE 6.2 (or later) installations should work.
# Red Hat 6.x users who want to install the Mozilla RPM must have at least
version 4.0.2 of rpm installed. There is an official update to rpm from Red Hat.

And I'm not using the RPM.  

Comment 15

15 years ago
*** Bug 206913 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
I have been periodically trying to install mozilla on SuSE 7.0
(kernel version: 2.2.16-SMP) without success for many months.
In fact, I filed a bug about this before, which is no longer
in bugzilla. I got the same replies and suggestions. However,
there's no getting around it: It gives the error message:
Fatal error [-618]: Couldn't open xpistub library
... and it won't install. This occurs despite the fact that
my system meets all the system requirements listed in the README.
This is a real bug, either of the installer or of the documentation.
Note that the documentation is inconsistent. The Release Notes
http://www.mozilla.org/releases/mozilla1.4b/#require
and the README file that is bundled with the download list
different requirements. Even within the Release Notes, the
requirements listed under "System Requirements" are different
from those under "Compatility Notes". The names of the downloaded
files are also not correctin the documentation.
I would like to be able to use Mozilla on my Linux machine,
but I still can't.

Comment 17

15 years ago
I found the older bug. It's number was 130144. I wasn't
able to find it at first because I thought I had filed it,
but actually I only added a comment to it.

Comment 18

15 years ago
> The Release Notes http://www.mozilla.org/releases/mozilla1.4b/#require
> and the README file that is bundled with the download list different 
> requirements. Even within the Release Notes, the requirements listed under 
> "System Requirements" are different from those under "Compatility Notes".

The release notes requirements are correct.
glibc 2.2 is required (included with Red Hat 7.x and higher).  libstdc++ is
currently statically linked (bug 204236) and so it doesn't matter what version
you have.

Comment 19

15 years ago
Confirming this on 1.4. Note: this is a machine that runs 1.0, 1.1, 1.2 AND 1.3
without any problems at all.

Downloaded linux installer from moz.org today, followed the instructions, ran
the installer as a normal user, chose:

Custom
Navigator + MailAndNews + PersonalSecurityManager
Changed the install directory to one where I had full priviledges
Pressed the install button.

Immediately got the error.

Note: even attempting the same procedure as root, I get precisely the same
problem, implying it's nothing to do with priviledges??

Comment 20

15 years ago
...on further investigation, following the comments in this bug and the
associated ones, the problem was that I ran mozilla-installer-bin.

This is mind-numbingly stupid - you have a file that is EXPLICITLY marked
executable in the TAR.GZ, AND it starts the installer OK, and appears to be the
correct file if you run it.

But it crashes with a totally undecipherable error (to anyone except a
developer, perhaps - note: there is no explanation, no suggested actions, nothing).
Confirming the problem with today's build on RedHat 8.0.
I've successfully installed several nightly builds before, last 200304????; that
was on RedHat 7.2.
I located /usr/lib/mozilla-1.0.1/libxpistub.so on my disk.  But even if I set
LD_LIBRARY_PATH to its directory, mozilla-installer fails with the same "Fatal
Error [-618]: Couldn't open xpistub library"

Comment 23

15 years ago
Just tried to install mozilla-i686-pc-linux-gnu-full-installer.tar.gz for
11-24-2003 and got "Fatal error [-618]: Couldn't open xpistub library"

Currently running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b)
Gecko/20031110 MultiZilla/1.5.0.4c installed from
mozilla-i686-pc-linux-gnu-sea.tar.gz for 11-10-2003 which is the latest nightly
being pointed to by the developer web page.

Comment 24

15 years ago
The error Message

"Fatal error [-618]: Couldn't open xpistub library"

also happens if there wasn't enough discspace on path and/or on "/temp".
Normaly mozilla should should bring "Not enough disc space".

Comment 25

15 years ago
Just tried to install mozilla-i686-pc-linux-gnu-full-installer.tar.gz for
12-01-2003 with the same error.

If the Mozilla development team really wants outside testing and participation,
this needs to be fixed now.  mozilla-i686-pc-linux-gnu-sea.tar.gz has not been
updated since 10-Nov-2003 10:30. That is the last version that worked for me.

Comment 26

15 years ago
The severity of the bug should be changed to "blocker" since the new Mozilla
truck build won't even install. That is pretty much a blocker in my estimation.

I have plenty of disk space, so that is not the problem.

Comment 27

15 years ago
John:
On

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/

I have

 mozilla-i686-pc-linux-gnu-full-installer.tar.gz 02-Dec-2003 16:30  11.4M  

so, there is a newer one and this is updated daily.
How is your harddrive partitioned?

Comment 28

15 years ago
Harddrive is one partition all root with 1664298 1k blocks free. /tmp is not a
file system.

FYI:  The link on the Mozilla developers web page
http://www.mozilla.org/developer/ for the Linux nightly build still points to
mozilla-i686-pc-linux-gnu-sea.tar.gz  10-Nov-2003 10:30

Comment 29

15 years ago
Using Debian Woody I also have this problem. I could install with the installer
successfully on October 30. So there must be a recent problem causing it.

Setting to blocker. Testing of the installer fails, so this component is blocked.

Since it is important to work in the release, asking for blocking, even if it is
late, sorry.

pi
Severity: normal → blocker
Flags: blocking1.6b?

Comment 30

15 years ago
john: The link points to

http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz

and this file is new ... maybe you see something from a proxy or from a cache.

Comment 31

15 years ago
There may be problems with
http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/unix/src2/nsXIEngine.cpp#662
aStub->handle = dlopen(libpath, RTLD_LAZY);

As in some lines later we don't give the error message back to the user, we
can't find out why this error occured and we can't reproduce it.

I think we should, at the moment, replace DUMP(dlerr); by printf("DLError: %s",
dlerr); so the users can report why it doesn't load the dynamic library.

Would set this as blocking 1.6 not 1.6b

Comment 32

15 years ago
Created attachment 136760 [details] [diff] [review]
it add's a prinf to standard output so the user can see the error message from dlopen ... can be removed later.

Comment 33

15 years ago
I cleard all cache from Mozilla. I followed the "Nightly Builds" link under
testing on the developers page to
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/

The file mozilla-i686-pc-linux-gnu-sea.tar.gz and the date is still 10-Nov-2003
10:30.

The other files are updated. The most recent file I see now is
mozilla-win32-svg-GDI-mathml.zip with a date of 04-Dec-2003 09:58.

I just used the Mozilla Linux link on the developers page under the "For
Testers" to download the file the link points to. Doing a diff between the file
I downloaded on 12-Nov-2003 finds no differences from the file I downloaded two
minutes ago. 

505 bash$ diff mozilla-i686-pc-linux-gnu-sea.tar.gz
mozilla-i686-pc-linux-gnu-sea1110.tar.gz
506 bash$

I would have suspected that since the file size is exactly the same, 
-rw-------    1 userxxx  group      15244312 Dec  4 09:34
mozilla-i686-pc-linux-gnu-sea.tar.gz
-rw-------    1 userxxx  group      15244312 Nov 12 14:04
mozilla-i686-pc-linux-gnu-sea1110.tar.gz

From a different host, I did and ftp connect to ftp.mozilla.org.
ftp> pwd
257 "/pub/mozilla.org/mozilla/nightly/latest" is current directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for directory listing.
total 523904
-rwxrwxr-x   1 root     7750     61890396 Nov 10 15:31
embed-i686-pc-linux-gnu.tar.gz
-rwxrwxr-x   1 root     7750      1700149 Dec  3 17:21 gecko-sdk-i586-pc-msvc.zip
-rwxrwxr-x   1 root     7750      1233680 Dec  3 17:36
gecko-sdk-i686-pc-linux-gnu.tar.gz
-rwxrwxr-x   1 root     7750     10842625 Dec  3 17:21 mozilla-i586-pc-msvc.zip
-rw-r--r--   1 root     7750     16545134 Dec  3 01:00
mozilla-i686-pc-linux-RH7.1-gnu-svg.tar.gz
-rwxrwxr-x   1 root     7750     11935539 Dec  3 17:44
mozilla-i686-pc-linux-gnu-full-installer.tar.gz
-rwxrwxr-x   1 root     7750        93954 Dec  3 17:44
mozilla-i686-pc-linux-gnu-installer.tar.gz
-rwxrwxr-x   1 root     7750     15244312 Nov 10 15:30
mozilla-i686-pc-linux-gnu-sea.tar.gz
-rwxrwxr-x   1 root     7750     12062797 Dec  3 17:51
mozilla-i686-pc-linux-gnu.tar.gz
-rwxrwxr-x   1 root     7750     15589324 Dec  3 14:46 mozilla-mac-MachO.dmg.gz
-rw-r--r--   1 root     7750     14955599 Dec  3 21:17 mozilla-os2.zip
-rwxrwxr-x   1 root     7750     29619800 Dec  3 19:07 mozilla-source.tar.bz2
-rwxrwxr-x   1 root     7750     37667217 Dec  3 19:13 mozilla-source.tar.gz
-rwxrwxr-x   1 root     7750     11784192 Dec  3 17:21 mozilla-win32-installer.exe
-rwxrwxr-x   1 root     7750       233472 Dec  3 17:21
mozilla-win32-stub-installer.exe
-rwxrwxr-x   1 root     7750     14275981 Dec  4 09:58
mozilla-win32-svg-GDI-mathml.zip
-rwxrwxr-x   1 root     7750     11878374 Dec  3 19:12
mozilla-win32-svg-libart-mathml.zip
226 Transfer complete.
ftp> bye
221-You have transferred 0 bytes in 0 files.
221-Total traffic for this session was 2173 bytes in 0 transfers.
221-Thank you for using the FTP service on mozilla.isc.org.
221 Goodbye.
447 $


Notice 
-rwxrwxr-x   1 root     7750     15244312 Nov 10 15:30
mozilla-i686-pc-linux-gnu-sea.tar.gz

So this file has not been updated since Nov 10 at any site I can get to.

Comment 34

15 years ago
Excuse, my fault.

Please use 
mozilla-i686-pc-linux-gnu-full-installer.tar.gz
instead of
mozilla-i686-pc-linux-gnu-sea.tar.gz

Comment 35

15 years ago
No problem. I can do that, but mozilla-i686-pc-linux-gnu-full-installer.tar.gz
is what has been giving this error.

The http://www.mozilla.org/developer/ web page needs to be updated. The link in
the section at the bottom of the page that reads:

Nightly Builds

Created most weekdays from the previous day's work, these will probably work,
but may not. Use them to verify that a bug you're tracking has been fixed.

    * Mozilla: Windows, Linux, MacOS X, etc.
    * Mozilla Firebird: Windows, Linux, MacOS X, etc.
    * Mozilla Thunderbird: Windows, Linux and MacOS X
    * Camino: MacOS X

needs to be updated. The "* Mozilla: Windows, Linux, MacOS X, etc." Linux link
points to mozilla-i686-pc-linux-gnu-sea.tar.gz.

Comment 36

15 years ago
mozilla-i686-pc-linux-gnu-full-installer.tar.gz of 04-Dec-2003 still fails.

Comment 37

15 years ago
If the bug you see of late isn't explicitly about "Error [-618}", you are likely
seeing bug  227105 / bug 227063. The problem is being worked on and is a blocker
for 1.6b.

Comment 38

15 years ago
 "Fatal Error [-618]: Couldn't open xpistub library" is the exact error message
from the nightly mozilla-i686-pc-linux-gnu-full-installer.tar.gz.

Comment 39

15 years ago
Ok, it seems nobody view the patch ... so I give you a compiled installer.

Download http://www.opiswelt.de/mozilla/mozilla-installer-bin and copy the file
to your latest mozilla-installer directory (so the old one is overwritten).

Then start the mozilla-installer (not mozilla-installer-bin directly) ... after
you get the error message you will see an error message on your console, please
tell me what there stand. (Mabe you don't have libstdc++.so.5 it seems that this
file isn't static compiled any more). But we will see.

Comment 40

15 years ago
It appears that the version of libc that is required has changed.

 ./mozilla-installer
./mozilla-installer-bin: /usr/lib/libstdc++.so.5: no version information
available (required by ./mozilla-installer-bin)
./mozilla-installer-bin: /usr/lib/libstdc++.so.5: no version information
available (required by ./mozilla-installer-bin)
DLError: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./libxpcom.so)

I have:

l /lib/libc*
-rwxr-xr-x    1 root     root      1459469 Jan  2  2003 /lib/libc-2.2.4.so
lrwxrwxrwx    1 root     root           13 Feb 16  2003 /lib/libc.so.6 ->
libc-2.2.4.so

If mozilla installer did not hide the actual error, we would have found this far
sooner.

I also have a problem with changing the required versions of libraries in the
middle of the development of a branch. I wonder how many others got zapped by
this and just didn't bother to persue it.

Comment 41

15 years ago
So it seems bug 227063 for you.

Comment 42

15 years ago
Also, I did not ignore your patch. I do not build from source, so patch did me
no good.

Comment 43

15 years ago
Created attachment 136939 [details] [diff] [review]
same patch but with diff -up
Attachment #136760 - Attachment is obsolete: true

Updated

15 years ago
Depends on: 227063

Updated

15 years ago
Attachment #136939 - Flags: review?

Updated

15 years ago
Attachment #136939 - Flags: superreview?(darin)
Attachment #136939 - Flags: review?(bsmedberg)
Attachment #136939 - Flags: review?

Comment 44

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

If darin thinks this is OK, I'll r= it, but I suspect that forced NSPR logging
would be a better solution for this kind of error logging.

Updated

15 years ago
Flags: blocking1.6b?
Flags: blocking1.6b-
Flags: blocking1.6?

Comment 45

15 years ago
I could install yesterdays installer version without problem (not using
http://www.opiswelt.de/mozilla/mozilla-installer-bin) on Woody. Anybody still
seeing a problem?

pi
Flags: blocking1.6? → blocking1.6-
Whiteboard: [Ignore comment 21 through comment 45; see comment 37 for why]

Comment 46

15 years ago
No reply. So WFM.

pi
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 47

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

clearing review requests
Attachment #136939 - Flags: superreview?(darin)
Attachment #136939 - Flags: review?(bsmedberg)

Comment 48

15 years ago
[00:45:58] <darin> opi: well, are you saying that the problem has not been fixed?
[00:46:08] <darin> opi: i see a WORKSFORME resolutoin
[00:48:30] <opi> darin: The problem up to yet is, every time a user missing a
lib that the installer needs the user get no hint and write a bug ... every time
we must drag it down ... the patch will write the problem to the console instead
of hiding this to the user.
[00:49:35] <opi> darin: As you see in the first comments we needed time to find,
why mozilla didn't installed on some mechines ... there are some dupes and deps
to this bug.
[00:50:17] <opi> darin: So the patch will explain more to the user instead of
only bringing the -618 error message
[01:00:43] <darin> opi: ok, please reopen the bug... and post what you have said
here to the bug.  thx
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 49

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

to comment #44:

We never used pr_logging inside the installer.

Normaly we need a rewrite of the installer GUI/process ... mybe then we can use
logging on every part of the installer.
Attachment #136939 - Flags: review?(darin)

Comment 50

15 years ago
(In reply to comment #49)
> We never used pr_logging inside the installer.
> 
> Normaly we need a rewrite of the installer GUI/process ... mybe then we can use
> logging on every part of the installer.

The installer does have ErrorHandler which should be used here, but it doesn't
work in this case because the error dialog box doesn't block the installer from
bailing.  I filed bug 235139 to fix that.  
Depends on: 235139

Comment 51

15 years ago
does not block development
Severity: blocker → critical

Comment 52

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

deferring to dveditz on this issue...
Attachment #136939 - Flags: review?(darin) → review?(dveditz+bmo)
(Assignee)

Comment 53

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

r=dveditz
Attachment #136939 - Flags: review?(dveditz+bmo) → review+

Comment 54

15 years ago
Comment on attachment 136939 [details] [diff] [review]
same patch but with diff -up

nix the extra whitespace and sr=darin
Attachment #136939 - Flags: superreview+

Comment 55

14 years ago
I've tried to install mozilla-i686-pc-linux-gnu-1.7rc2-installer.tar.gz 
on my gentoo linux box as well, and got the error 
FATAL[-618]: Couldn't open xpistub library. 
 
I also tried the nightly build from today and same error. 
 
root@thomas:/home/thomas/download/mozilla-installer ls -l /usr/lib/libstdc++* 
-rwxr-xr-x  1 root root 262988  8. Feb 
15:07 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 
-rwxr-xr-x  1 root root 334940  8. Feb 
15:07 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so 
lrwxrwxrwx  1 root root     30  8. Feb 15:07 /usr/lib/libstdc++-libc6.1-1.so.2 
-> libstdc++-2-libc6.1-1-2.9.0.so 
lrwxrwxrwx  1 root root     31  8. Feb 15:07 /usr/lib/libstdc++-libc6.2-2.so.3 
-> libstdc++-3-libc6.2-2-2.10.0.so 
lrwxrwxrwx  1 root root     20  8. Feb 15:07 /usr/lib/libstdc++.so.2.7.2 -> 
libstdc++.so.2.7.2.8 
-rwxr-xr-x  1 root root 226168  8. Feb 15:07 /usr/lib/libstdc++.so.2.7.2.8 
lrwxrwxrwx  1 root root     18  8. Feb 15:07 /usr/lib/libstdc++.so.2.8 -> 
libstdc++.so.2.8.0 
-rwxr-xr-x  1 root root 255728  8. Feb 15:07 /usr/lib/libstdc++.so.2.8.0 
lrwxrwxrwx  1 root root     18  8. Feb 15:07 /usr/lib/libstdc++.so.2.9 -> 
libstdc++.so.2.9.0 
-rwxr-xr-x  1 root root   3772  8. Feb 15:07 /usr/lib/libstdc++.so.2.9.0 
 
If you need further infos, no problem. 
 
Thanks Thomas Braun 

Comment 56

14 years ago
Same error with firefox-i686-linux-gtk2+xft-installer.tar.gz 

Comment 57

14 years ago
The mozilla linux installer should give you output on the console starting with
"DLError:" ... need the line to know what is missing.

Does the non-installer linux build works?

Comment 58

14 years ago
(In reply to comment #57)
> The mozilla linux installer should give you output on the console starting with
> "DLError:" ... need the line to know what is missing.

the patch here was never checked in, so it's not going to print anything.

Comment 59

14 years ago
As the last poster said, there is no output of the installer, only the
gui-message I posted, nothing more on stdout.
The following versions without installer work properly for me:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-i686-linux-gtk2+xft.tar.gz
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7/mozilla-i686-pc-linux-gnu.tar.gz

Comment 60

14 years ago
I have seen this bug with Firefox nightly builds from the past few days and I
have experienced it both with Mozilla 1.7 RC3 and Firefox 0.9 RC.

The non-installer builds of both work fine.

Comment 61

14 years ago
Requesting blocking 1.8a2, there is a patch attached (it may need updating, I
have no idea) and it is already reviewed. Plus it seems to be a trivial patch.
(I would say 1.7 but it is almost out the door, AFAIK)
Flags: blocking1.8a2?

Comment 62

14 years ago
Created attachment 151075 [details] [diff] [review]
same patch + removes tabs

this code is full of tabs...
Attachment #136939 - Attachment is obsolete: true

Comment 63

14 years ago
ok.  the patch is in.  I don't think there was ever a real bug resulting in the
messsages (only failed library dependencies).

resovling as FIXED.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Comment 64

14 years ago
Don't need a blocking1.8a2? anymore then.
Flags: blocking1.8a2?

Comment 65

14 years ago
(In reply to comment #63)
> ok.  the patch is in.  I don't think there was ever a real bug resulting in the
> messsages (only failed library dependencies).
> 
> resovling as FIXED.

Slackware 9.0, firefox 0.9x installer fails with the message described in this
bug.  "Couldn't open xpistub library."  No console output.

I downloaded and ran the "non-installer" version.  That fails with the message:

root@ellen:/usr/src/firefox# ./firefox
./firefox-bin: /lib/libpthread.so.0: version `GLIBC_2.3.2' not found (required
by ./libnspr4.so)

According to the README:

        -The following library versions (or compatible) are
         required: glibc 2.1, XFree86 3.3.x, GTK 1.2.x, Glib
         1.2.x, Libstdc++ 2.9.0. Red Hat Linux 6.0,
         Debian 2.1, and SuSE 6.2 (or later) installations
         should work.

root@ellen:/usr/src/firefox# ls -al /lib | grep libc
-rwxr-xr-x    1 root     root      1435624 Mar  5  2003 libc-2.3.1.so
lrwxrwxrwx    1 root     root           13 Sep  6  2003 libc.so.6 -> libc-2.3.1.so

Mozilla 1.7 is working fine and I'll continue to use it.  When I get around to
upgrading to slack 10, I will try again.

If this error message is accurate, then the README included with the firefox
installation needs to be updated to describe the correct library requirements.
Unless I've made some other mistake, this would seem to indicate that firefox
has forked away from Mozilla in its base reqs. 

If the error message generated by the installer is the result of this error with
glibc (or any other like it), then that is a bug in the installer -- it is
generating an irrelevant and misleading error message.

mp
Product: Browser → Seamonkey

Updated

9 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.