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.
dup *** This bug has been marked as a duplicate of 78874 ***
No. This _might_ be described as a dupe of bug 68604, but it is unfair to call it a dupe of that bug.
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++.
over to Samir.
Again: There is work in progress in bug 78874 to deal with this.
*** Bug 79170 has been marked as a duplicate of this bug. ***
I could use xmessage to show the error message in X window but it uses Athena widgets so it is not pretty.
BTW would README file be better destination for installer? "More information can be found in the installation and release notes, found at README file."
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.
Samir: nope, the current patches for bug 78874 won't resolv the problem for installer.
% 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.
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.
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?
(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.
I saw this on a daily build from yesterday, commercial.
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?
I believe this is fixed. I have not heard of other reports on this. I'll check with Asa and Jimmy Lee.
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.
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
ok since compiler change