installer can't start: requires unavailable lib: libstdc++-libc6.1-2.so.3

VERIFIED FIXED in mozilla0.9.1

Status

SeaMonkey
Installer
--
major
VERIFIED FIXED
17 years ago
7 years ago

People

(Reporter: Leston Buell, Assigned: Syd Logan)

Tracking

({relnote})

Trunk
mozilla0.9.1
x86
Linux
relnote

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Starting with the May 4, 2001 trunk builds, i cannot start the mozilla-installer
script. I get the following error:

   ./mozilla-installer-bin: 
   error while loading shared libraries: 
   libstdc++-libc6.1-2.so.3: cannot open shared object file: 
   No such file or directory

The May 5 0.9 builds do not have this problem. Neither do trunk builds up to
2001050315.

Comment 1

17 years ago
dup

*** This bug has been marked as a duplicate of 78874 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 2

17 years ago
ver
Status: RESOLVED → VERIFIED

Comment 3

17 years ago
No. This _might_ be described as a dupe of bug 68604, but it is unfair to call 
it a dupe of that bug.
Status: VERIFIED → UNCONFIRMED
Component: Browser-General → Installer
Resolution: DUPLICATE → ---

Comment 4

17 years ago
ssu: the way i see it, there are two reasonable fixes for this bug.
a) Fix the installer script to check for the library and carp w/ an 
explanation+relnote/bugnote link
b) Make the installer statically linked to libstdc++ (I don't care which 
version, whichever the build system has available).

I'd prefer that we do (b).  If we do (b), we still need a warning either in the 
installer or in run-mozilla.sh explaining that we require a certain version of 
libstdc++.
Assignee: asa → ssu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: relnote
QA Contact: doronr → gemal
Summary: installer can't start: can't open libstdc++-libc6.1-2.so.3 → installer can't start: requires unavailable lib: libstdc++-libc6.1-2.so.3

Comment 5

17 years ago
over to Samir.
Assignee: ssu → sgehani

Updated

17 years ago
QA Contact: gemal → gbush

Comment 6

17 years ago
Again: There is work in progress in bug 78874 to deal with this.

Comment 7

17 years ago
*** Bug 79170 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
Created attachment 33426 [details] [diff] [review]
patch for printing better error message

Comment 9

17 years ago
I could use xmessage to show the error message in X window but it uses
Athena widgets so it is not pretty.

Comment 10

17 years ago
BTW would README file be better destination for installer?

"More information can be found in the installation and release notes,
found at README file."

Comment 11

17 years ago
Asko,
Thank you for the patch.  I think that the resolution for bug 78874 will fix
this and we won't need to check for libs sepcifically.  

cls,
Please update us on the accuracy of my last statement.  If I am to take explicit
action please indicate the same and vend me a clue: this looks like build
changes that have affected the mozilla binary as well.

Comment 12

17 years ago
Samir: nope, the current patches for bug 78874 won't resolv the problem
for installer.

Comment 13

17 years ago
% ldd xpinstall/wizard/unix/src2/mozilla-installer-bin | grep libstdc
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3

So installer cannot be started without proper libstdc++ and patching browser
won't help installer.
(Reporter)

Comment 14

17 years ago
I hope that if you direct people to the README file, that the README is actually
updated. I've added a comment to that effect that this library issue be
mentioned in the README in bug 58859.

Updated

17 years ago
Keywords: nsbeta1
(Assignee)

Comment 15

17 years ago
cls, I am thinking the right thing to do is override LIBS in the installer
wizard Makefile.in will fix this problem, how does that sound?
Assignee: sgehani → syd
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.1

Comment 16

17 years ago
(Ugh. How many of these bugs are there?)

The proper thing to do would be to statically link against libstdc++ if GNU_CXX
is set.  However, since the compiler on the nightly build machine has been
reverted, I'm pretty sure this is no longer an issue.

Comment 17

17 years ago
I saw this on a daily build from yesterday, commercial.

Comment 18

17 years ago
The compiler was reverted this morning.  Wait for the 8pm build or even the
post-carpool landing build.
Did the compiler change fix this bug?

Comment 20

17 years ago
I believe this is fixed.  I have not heard of other reports on this.  I'll check
with Asa and Jimmy Lee.

Comment 21

17 years ago
looks good to me. tested 051608 builds (morning and afternoon) and they worked
fine for me. 
Compiler was reverted, this is no longer a problem.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
Passing on some info I got to get the older libaries...

The older versions (which should work on redhat 6.x machines) can be
found at:
http://rpmfind.net/linux/RPM/redhat/6.2/i386////libstdc++-2.9.0-30.i386.html
and
http://rpmfind.net/linux/RPM/redhat/6.2/i386////egcs-1.1.2-30.i386.html

Comment 24

17 years ago
ok since compiler change
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.