i installed this morning's opt commercial bits via claudius's new_build script, and it launched initially. i was trying to repro bug 38941 (which i couldn't) which involved exiting the browser. when trying to start it again, all i get is the following in the console: sairuh@hopey 86: ./netscape .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/u/sairuh/seamonkey/00051109/package LD_LIBRARY_PATH=/u/sairuh/seamonkey/00051109/package/Cool:/u/sairuh/seamonkey/00051109/package:/u/sairuh/linux/seamonkey/package LIBPATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool SHLIB_PATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool XPCS_HOME=/u/sairuh/seamonkey/00051109/package/Cool MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= ************************************************** nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot open shared object file: No such file or directory ************************************************** ************************************************** nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot open shared object file: No such file or directory **************************************************

does this happen for anyone running mozilla on linux today?

marking this a dogfood/smoketest blocker...until a workaround is found. :-)

unable to repro using mozilla bits.

Putting on [dogfood+] radar.

tried this to no avail: "trashed," ie, moved my .mozilla/ dir to another name (old.mozilla/) so that the registry file and whatnot are created again, freshly. still get the errors when starting up nscp.

hokay, this is NOT a problem if i install by deflating the zip'd tarball. the problem here seems to be claudius' installer script. cc'ing him and resolving this as invalid. sorry about the fuss!

np. verif.

I'm seeing this problem for the second time now: Could not obtain CmdLine processing service ************************************************** nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot open shared object file: No such file or directory ************************************************** I'm on PC/Linux. It doesn't occur with the nightly mozilla binaries. Once in a while I do the following 1. download the mozilla-source.tar.gz from the ftp server 2. compile it in a separate directory with --disable-debug --enable-optimize 3. run mozilla in the build/dist/bin directory, with or without gdb. The first time I did it with the 4/28 source, and this installation is still working. The second time I compiled mozilla from the 5/8 sources (I think), but very soon (only very few launches after the installation) it became unusable: Mozilla quit at startup with the above error message. Removing my ~/.mozilla directory did not help. I deleted that installation because I thought this had been caused by some manipulation in the source tree (I had tried to back out a small change in my local tree, but had run into conflicts). However, recently I built mozilla for the third time, from the 5/13 sources, and I'm 100 % sure that after make completed, I did not change anything in either the source tree or the build tree. And it's the same again: I started mozilla very few times (I guess between 1 and 5 launches), and now it's suddenly completely unusable again: Everytime I launch mozilla, it immediately quits with the above error. This is really bad, because I can't afford to download and compile mozilla everytime I want to use it. Maybe something has changed between 4/28 and 5/8 that doesn't allow me to launch mozilla directly from the dist/bin directory? I'd like to know if there's any workaround for this. Note that I ran several different mozilla versions between the launches of the self-compiled version, so that may have had side-effects. Nevertheless I would expect that these side-effects are local to the ~/.mozilla directory, and would have gone away by deleting it. I leave it up to you if you want to reopen this bug. If I can help resolving this problem, please advise. CC self.

Is this on a network mounted drive (NFS stale)? What are the write permissions for 'dist' directory? Are you running/compiling as more than one user?

Yes, this is on an NFS. But the 4/28 build is on the same partition, so this does not explain why the new builds have the bug, and the old one still works. The write permissions for dist are drwxr-xr-x 6 afranke omegagrp 512 May 14 05:06 dist/ I have been compiling and running as the same user until now. But since you asked, I tried to run both installations as a different user (which is in a different group), and the results are the same: 4/28 build works fine, but the 5/13 build doesn't work.

One thing (independent of any other issues): the first time you build, with sources dated 5/13 onward, you *must* delete your dist/ directory before you build -- see danm's note n.p.m.seamonkey. back to the initial problem: I can't say why this is failing, but the error message indicates a complete inability to load components (or at least some components). This could be simply due to stale NFS file handles and the like, or some unintended change in access permissions. See also bug #33344

Many thanks for the tips! The problem is solved! About the first note: I always build in a newly created build directory, so there is no problem with the dist directory. But the tip with bug 33344 was a hit. Here's the story: I had downloaded mozilla again in the meantime, compiled it, made a backup of the complete installation, and tried to reproduce the problem. By using the window manager to _kill_ the a file download dialog while running mozilla in gdb, I triggered a crash (no problem with that), and next time mozilla was started, it exited with code 01 right after ~nsProfile. Repeated attempts produced the same results. Deleting ~/.mozilla did not help: After that mozilla segfaulted in nsProfile::LoadDefaultProfileDir everytime. Then I took a look at bug 33344. The problem there seems to be the write permission to component.reg. So I moved away my component.reg, removed ~/.mozilla and mozilla started up fine again, in both installations! Conclusion: If a self-compiled version of mozilla suddenly begins to quit on startup with whatever error, it is most likely that removing dist/bin/component.reg will fix the problem.