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)

x86
Linux
defect

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.)
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
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
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 . . .
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 . . .
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
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 . . .
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.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
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!
that sort of thing happens frequently with mozilla especially when dealing with different milestones. verifying invalid.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.