Closed
Bug 61892
Opened 24 years ago
Closed 24 years ago
./regxpcom: error in loading shared libraries: libplds4.so: cannot open shared object file: No such file or directory
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: bts, Assigned: cls)
Details
When I try to run the newly-installed M18 version of Mozilla (why won't it let
me enter a version up there in the Version field of Bugzilla anyway?), I get
this before a window even comes up:
RegSelf Unicode to Big5 converter complete
RegSelf Unicode to x-x-big5 converter complete
RegSelf Big5 to Unicode converter complete
RegSelf Shift_JIS to Unicode converter complete
RegSelf EUC-JP to Unicode converter complete
RegSelf ISO-2022-JP to Unicode converter complete
RegSelf Unicode to Shift_JIS converter complete
RegSelf Unicode to EUC-JP converter complete
RegSelf Unicode to ISO-2022-JP converter complete
RegSelf Unicode to jis_0201 converter complete
RegSelf Unicode to jis_0208-1983 converter complete
RegSelf Unicode to jis_0212-1990 converter complete
*** Deferring registration of sample JS components
-*- filepicker: registering (all right -- a JavaScript module!)
*** Registering -chat handler.
*** Registering x-application-irc handler.
*** Registering irc protocol handler.
*** Registering sample JS components
/usr/local/mozilla/run-mozilla.sh: line 72: 4066 Segmentation fault $prog
${1+"$@"}
I have Linuz Mandrake 7.1; I normally run Netscape 4.73 (that's what I'm
reporting this one); Netscape 6.0 I also test-installed tonight; I managed to
crash it in pretty short order (it sent one of those "full circle" report to
Netscape--pretty slick stuff), but at least it came up.
I previously installed a much earlier version of Mozilla (MS4, maybe?), and it
also came up ok for me.
I picked the "full" install of Mozilla; for Netscape 6.0 I picked custom and
installed all expect for the foreign-language customizations.
(I'm hoping that knowing what I did with Netscape 6.0, which works, helps you
narrow in on what's wront with Mozilla MS18.)
Comment 1•24 years ago
|
||
Did you install Mozilla as root but try to run it as a normal user? If so, you
first need to run the regxpcom and regchrome programs in the mozilla binary
directory as root.
you must run ./regxpcom && ./regchrome as installer [root?] before allowing a
poor mortal to try to run mozilla. Or you could run mozilla as root.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•24 years ago
|
||
Boy, what fantastic response time! I'm impressed. However, I can't let you
close this one out as "resolved" quite so quickly, I fear.
I *did* install it as root but I also *ran* it as root.
If I try to run it as a normal user, I don't get the segmentation fault; rather,
it just hangs.
It is my habit in such situations to first run things as root (which presumably
eliminates any possibility of permission errors & what-not messing me up), and
once I've verified that works, I figure out how to run it as a normal user.
Moreover, if I try to run the suggested programs (just to see if they helped
any), they aren't working for me:
[bts@i7500 mozilla]# ./regxpcom
./regxpcom: error in loading shared libraries: libplds4.so: cannot open shared
object file: No such file or directory
[bts@i7500 mozilla]# ./regchrome
./regchrome: Command not found.
If I work around that first problem by doing "ln -s *.so /lib", it gives me a
warning about MOZILLA_FIVE_HOME not being set, but I still have the second
problem (no ./regchrome file).
More importantly, I still have the original problem: I can't run mozilla as root
without the segv. It does have one consequence, however: now when I run it as
an ordinary user, rather than handing, it gets the same segv as root gets. Is
it possible that ./regchrome has been eliminated and incorporated into regxpcom
sometime recently? Running regxpcom by itself does successfully get "joe-bob
user" to function the same as root, which I guess is some sort of progress . . .
Finally, as a brief comment: surely it is pretty conventional to install as root
and run as an ordinary user anyway (even though that's not what *I* did);
therefore, I'd suggest adding a note about this to the basic installation notes
/ README file.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Yeah we're working on the notes. But that's in another bug, which from analysis
is not your bug.
Clobbering summary with an excerpt from your most recent comment. I'm sorry
regxpcom and regchrome didn't fix it, but they gave us a hint.
Let's try build config. And if you could possibly tell us which type of archive
you have. [One form should include regchrome.] There are also a few files you
should probably zap (mozreg.dat). As always if you can grab a current nightly
build from /nightly/2000-xx-xx-xx/, try it and mention the url for it that will
help.
Assignee: asa → cls
Component: Browser-General → Build Config
QA Contact: doronr → granrose
Summary: /usr/local/mozilla/run-mozilla.sh: line 72: 4066 Segmentation fault → ./regxpcom: error in loading shared libraries: libplds4.so: cannot open shared object file: No such file or directory
Reporter | ||
Comment 5•24 years ago
|
||
I didn't do anything anywhere near that fancy. I just went grabbed the plain
old M818 installation package from the Mozilla home page,and picked the "Full
Installer." I've installed previously with the raw gzip file, but I figured I'd
try the new fancy installer; the installer itself seemed to work ok, but then I
got the segv . . .
Anyway, what I got, to be precise, was mozilla-i686-pc-linux-gnu-sea-M18.tar.gz
package from http://www.mozilla.org/projects/seamonkey/release-notes/ labeled
"x86 Full Installer (8.2 MB)". Like I said, nothing fancy.
I'll be happy to grab the nightly build or anything else you'd like me to; I'm
not afraid of building and all that, but that's not what I did in this case.
And of courrse the vanilla "full installer" M18 doesn't have a make file or
config at all. Also, there was no URL that I was viewing; this happens when
Mozilla is trying to initilize--it hasn't even brought up a window yet when it
dies.
I'll try the nightly build to see what happens . . .
Reporter | ||
Comment 6•24 years ago
|
||
I don't mean to sound like a moron or anything, but when I tried the daily build
I got this:
./mozilla-bin: error in loading shared libraries:
/usr/local/src/package/components/libaimstat.so: undefined symbol:
Append__9nsCStringPCci
I am currently building the M18 distribution from source. I was going to wait
for the results before I committed this update, but it's taking a l-o-n-g time
and I'm having to clean up disk space (one what's a darn big drive), what with
having 2 binary distributions of netscape, 2 binary distributions of mozilla,
and a source distribution of mozilla all on the same drive.
I'll let you know the results when I have them . . .
Comment 7•24 years ago
|
||
could be a corrupt registry. try running regxpcom and regchrome via the
run-mozilla.sh script (e.g. # ./run-mozilla.sh regxpcom) which sets the
LD_LIBRARY_PATH and other variables correctly so they can execute. You might
also try removing your component.reg file as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 8•24 years ago
|
||
Neither of those helped.
As for building M18 myself, it generates a number of warnings and still fails in
much the same way:
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../../dist/include/nsCOMPtr.h, line 649
###!!! Break: at file ../../../dist/include/nsCOMPtr.h, line 649
./run-mozilla.sh: line 72: 2372 Segmentation fault $prog ${1+"$@"}
As for the nightly builds, I haven't figured out how to do that yet . . .
Reporter | ||
Comment 9•24 years ago
|
||
Ok, I checkout out & built the latest & greatest from the cvs respository.
Same thing:
./run-mozilla.sh: line 72: 13173 Segmentation fault $prog ${1+"$@"}
Also tried re-deleting the component registry and re-running regxpcom &
regchrome; same results.
Reporter | ||
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 10•24 years ago
|
||
Ok, thanks to I friend, I finally did this:
rm -r ~/.mozilla
Now it works! (For both root and my user account.)
I'm guessing that this is one of those "pre-release" issues and it's expected to
work this way, so I've taken the liberty of marking it INVALID. However, I
certainly hope that the production versions will deal with this situation a bit
more elegantly!
Comment 11•24 years ago
|
||
that sort of thing happens frequently with mozilla especially when dealing with
different milestones.
verifying invalid.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•