gtk2/2003-01-27-14-trunk RPMs: mozilla tries to open /usr/lib/mozilla-1.3b/libxpcom.so and fails (to start)

RESOLVED FIXED

Status

Core Graveyard
Embedding: GRE Core
--
critical
RESOLVED FIXED
16 years ago
2 years ago

People

(Reporter: Ogi Bor, Assigned: blizzard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030127
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030127

Mozilla fails to start.
Last line of strace:
open("/usr/lib/mozilla-1.3b/libxpcom.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
_exit(1)                                = ?


rpm -ql mozilla | grep libxpcom.so
/usr/lib/libxpcom.so

ln -s /usr/lib/libxpcom.so /usr/lib/mozilla-1.3b/libxpcom.so solves the problem.


System is i686 Redhat 8.0 with latest patches installed.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
to blizzard
Assignee: asa → blizzard
*** Bug 190910 has been marked as a duplicate of this bug. ***
strace shows:

open("/home/bbaetz/.gre.config", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/gre.conf", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("/usr/lib/mozilla-1.3b/libxpcom.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
_exit(1)                                = ?

Apart from the exit(1) with no error message if stuff can't be found (Is there a
bug on this? A debug-only NS_WARNING and a commment in nsAppRunner.cpp isn't
that useful), this is failing to search the LD_LIBRARY_PATH.

I can get the build to start up by setting USE_LOCAL_GRE=1 first, but ISTM that
trying the operating system standard path for a library is better than just
giving up and exiting. :-)

(BTW, can someone point me to a doc pointing out what problems the GRE solves
that the normal unix .so stuff doesn't? Since APIs are frozen, dropping newer
1.x versions in place should Just Work.
http://www.mozilla.org/projects/embedding/MRE.html lists several problems, but
even if you do want per-verson installs, a wrapper script setting
LD_LIBRARY_PATH to
/usr/local/lib/mozilla-<vnum>:/usr/lib/mozilla-<vnum>/:<binpath>/components
would solve those. Since the mozilla-bin is linked to libmozjs, you need that
anyway... The link from that page to the Unix Install page is 404, so that
doesn't help me)
Assignee: blizzard → chak
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → Embedding: GRE Core
Ever confirmed: true
QA Contact: asa → ashishbhatt
Actually, USE_LOCAL_GRE=1 doesn't work, sorry - it works with the x-remote stuff.

Comment 5

16 years ago
try this -  create a file /home/bbaetz/.gre.config

in it, have the contents be:

[1.3b]
GRE_HOME=<path-to-mozilla-bin-dir>


where <path-to-mozilla-bin-dir> points to what the name suggests.
[bbaetz@mango bbaetz]$ cat .gre.config
[1.3b]
GRE_HOME=/usr/lib/

strace mozilla:
...
open("/home/bbaetz/.gre.config", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=26, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40013000
read(3, "[1.3b]\nGRE_HOME=/usr/lib/\n", 4096) = 26
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40013000, 4096)                = 0
open("/etc/gre.conf", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("/usr/lib/mozilla-1.3b/libxpcom.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
_exit(1)                                = ?

But I shouldn't have to specify somewhere which is in the standard libpath.

Comment 7

16 years ago
->Dougt
Assignee: chak → dougt

Comment 8

16 years ago
over to blizzard who owns the RPM's.  I am not sure where stuff gets installed
using the RPM's.  Blizzard, if you need any help, let me know.

bradley - i am not sure what the problem is.  The GRE isn't suppose to be
installed into the standard libpath.  If this is a problem, please lets discuss
it outside of this bug report.
Assignee: dougt → blizzard

Comment 9

16 years ago
Mozilla can be started by the libxpcom.so symbolic link shown above.
However Java Console is not active when j2sdk (or j2re) is set.

I sometimes checking trunk sources at the FTP site. This problem
doesn't occur before 2003011608 sources. And it occurs after
2003011708.
(Assignee)

Comment 10

16 years ago
Hmm.  The GRE has messed with things.  Looks like I need to hack the rpms again.
 Yay.

Comment 11

16 years ago
I checked the latest gtk2 experimental RPM packages and this bug seems to be fixed.
(Reporter)

Comment 12

16 years ago
In 2003-02-18-12

$ rpm -ql mozilla | grep libxpcom.so
/usr/lib/mozilla-1.3b/libxpcom.so

Therefore everything works as it should now.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.