From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.15 i586) BuildID: not accessible The program does not start giving the following error: ...libnspr4.so: undefined symbol: __bzero Reproducible: Always Steps to Reproduce: 1.gunzip/untar mozilla-i686-pc-linux-gnu-M16-mathml-svg.tar.gz in a directory 2.cd to that directory 3.call ./run-mozilla.sh Actual Results: Expected Results:
reassigning to Samir.
Assignee: ssu → sgehani
Not an installer bug. This is a bug with the tarball. Reassiging to browser-general component and default owner.
Assignee: sgehani → asa
Component: Installer → Browser-General
QA Contact: gbush → doronr
reproter, did you delete the previous version of mozilla?
Does running the 'mozilla' script, which runs run-mozilla, which runs mozilla-bin, work?
1) The previuos version was deleted 2) Both running 'mozilla' and 'run-mozilla.sh' the result is the error message about the undefined symbol __bzero.
adding firstname.lastname@example.org to cc: list. Lourens Veen, you were seeing this error undefined symbol __bzero in bug 15970 Did you solve that problem?
No, never solved it. I suspect it has to do with the libc version used. I seem to have an old one (it came with SuSE 6.1) which also has the dlopen()-is-not-thread-safe bug. I'll update to 6.4 soon (as soon as I have that fast net connection), and I'll see if a new libc6 solves the problem then. Sorry for not replying earlier, I was on holiday. Perhaps packing the libc6 used with the binary helps? Or link statically? Lourens
Claudio, does this bug occur in the nightly builds? Does this occur with the non-mathml tarball? Also, can you please post specific information here about your distribution, kernel version, etc. Thanks.
The symbol __bzero seems to be defined only on recent libc on linux. (It's defined in the header string.h of recent libc-devel include files) I don't known the exact version number of libc where it appears first. I know that it's undefined in libc-2.0.7 and defined on libc-2.1.2 / libc-2.1.3 Perhaps mozilla should be compiled with an old version of string.h or better should require a recent libc library.
Claudio, would you post the glibc version you have? I have a feeling that Deigo has hit the problem right on the head. Are you using an older Mandrake distro?
Is this supposed to be a feature? I just assumed it would bring up Raptor.
Asa, maybe this is something we need to place promiently in the release notes if it's not there already. The linux builds are built on RedHat 6.0 systems which use glibc 2.1. Therefore, the minimum required version of glibc is 2.1. Builds have been known to work (occassionally) when built under glibc 2.0.7 but they aren't officially built nor supported (due to known race problems with the 2.0 dynamic loader). Wrt bundling the libc used, afaik, there's practically no possibility of that happening at this point. The same goes for gtk/glib/libIDL bundling.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
Hi, sorry for the delay. I made the test using Debian 2.0, Linux 2.0.36 and 2.2.16, on a diskless workstation from both mathml and non-mathml. Library was libc.so.6 (0x400100000). Bye, Claudio
This bug is linked to from the compatibility information in the release notes for Mozilla 1.4rc1 where it says that glibc 2.1 or newer is required. This is not true. Mozilla now requires glibc 2.2 or newer. Thus, I won't be using any newer Mozilla's until I reinstall with glibc 2.2.
The build machines were recently upgraded from RedHat 6.2 to RedHat 7.1 or 7.3 (I forget which). That's been discussed in other bugs.
Others happening across this may wish to read the following bug, as well: http://bugzilla.mozilla.org/show_bug.cgi?id=205291 Admittedly, I haven't read too much about the reasoning for this, but it seems silly. Mozilla 1.3 and some of the later nightlies worked fine on my glibc 2.1 machine. Can't a version linked to glibc 2.1 be created, as well?
You need to log in before you can comment on or make changes to this bug.