/home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

RESOLVED FIXED in mozilla1.8rc1

Status

()

Toolkit
Application Update
--
major
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: Darin Fisher)

Tracking

({fixed1.8})

unspecified
mozilla1.8rc1
x86
Linux
fixed1.8
Points:
---
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
When I update I get:

/home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries:
libmozjs.so: cannot open shared object file: No such file or directory

...after the updater has run.
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Flags: blocking1.8rc1?
Target Milestone: --- → Firefox1.5rc1

Comment 1

12 years ago
Is this just an error or does it prevent the update (or the app) from working?
Could this be a permissions issue related to which user installed the app?
I can reproduce this starting provided that I launch Firefox from a different
directory than it is unpacked to, eg ~/test/firefox/firefox -P, rather than
[~/test/firefox] ./firefox -P

The update still applies ok (doesn't fall back from partial to complete update,
buildID incremented from 2005101204 to 2005101304), but the application fails to
relaunch afterwards. Calling ~/test/firefox/firefox again launches the browser
without problems.

CC'ing startup-foo-master bsmedberg
Darin, can you think of a reason why the LD_LIBRARY_PATH would be wrong after
updating?
(Assignee)

Comment 4

12 years ago
No, I can't imagine how that could happen, but it must be happening.
(Assignee)

Comment 5

12 years ago
bsmedberg: actually, i suspect it must be the case that LD_LIBRARY_PATH includes
a relative path instead of an absolute path.  when applying the update, we chdir
into the firefox application directory, and then we spawn the updater, which
spawns firefox again into the application directory.  at that point, the current
directory is no longer what it was when "firefox" the shell script ran.  so, my
guess is that we must not be setting an absolute path in LD_LIBRARY_PATH.

Comment 6

12 years ago
Not going to block on this. Ben, if you can come up with something here, let us
know and we'll evaluate a patch but this isn't high impact enough -- it's my
understanding that next time you run the update works so there's a simple
workaround.
Flags: blocking1.8rc1? → blocking1.8rc1-

Comment 7

12 years ago
Jay ran into this today too. 
(Assignee)

Comment 8

12 years ago
Ian and I looked into this a bit today, and it turns out that my hunch was
correct.  The problem is that LD_LIBRARY_PATH contains a relative file path.  I
suspect that the best solution here is to pass the original working directory to
updater on the command line and have the updater chdir back to the original
working directory before launching firefox.

Comment 9

12 years ago
Benjamin, any chance you could keep poking at this over the next day or so?
Darin already has a lot on his plate. As Asa said, we'd still be interested in
evaulating a fix for this.

Comment 10

12 years ago
If we can come up with a quick, low-risk patch for this, I would like to see
this get into RC1.  Definitely not high impact for all of our users (if we count
Windows), but I think for Linux users, this is going to affect most of them. 
From what I understand, this is a problem if you are trying to run the app from
any dir other than the install dir...which many Linux users do all the time.

So if we want to keep our Linux users happy, this is one of those really
annoying bugs that we should get fixed if we want to keep a positive light on
Software Update... what's the point of making a huge deal of it if you can't
seemlessly update a build and expect it to startup after the update is applied?!

Darin/Benjamin: Please submit a patch so we can renominate this and get it in.
Flags: blocking1.8rc1- → blocking1.8rc1?

Comment 11

12 years ago
Jay accidentally set blocking1.8rc1?.  Setting it back to blocking1.8rc1- on his
behalf.
Flags: blocking1.8rc1? → blocking1.8rc1-
(Assignee)

Comment 12

12 years ago
I have a patch for this.
(Assignee)

Comment 13

12 years ago
Created attachment 200291 [details] [diff] [review]
v1 patch

This implements the solution from comment #8.
Attachment #200291 - Flags: review?(benjamin)
Comment on attachment 200291 [details] [diff] [review]
v1 patch

Eesh... perhaps (not now) we should think about whether we should pass a
directory to updater instead of changing directory there in the first place.
Attachment #200291 - Flags: review?(benjamin) → review+
(Assignee)

Comment 15

12 years ago
> Eesh... perhaps (not now) we should think about whether we should pass a
> directory to updater instead of changing directory there in the first place.

Yeah, moving all of the chdir business into updater would be a lot cleaner.
(Assignee)

Updated

12 years ago
Attachment #200291 - Flags: approval1.8rc1?

Updated

12 years ago
Attachment #200291 - Flags: approval1.8rc1? → approval1.8rc1+
(Assignee)

Comment 16

12 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

12 years ago
fixed1.8
Keywords: fixed1.8

Comment 18

12 years ago
Could the patch in this bug have caused bug 313623?
(Assignee)

Comment 19

12 years ago
I don't see an obvious connection other than the check-in times. I'll investigate to see what I can come up with.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.