Last Comment Bug 312360 - /home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory
: /home/ianh/firefox/firefox/firefox-bin: error while loading shared libraries:...
Status: RESOLVED FIXED
: fixed1.8
Product: Toolkit
Classification: Components
Component: Application Update (show other bugs)
: unspecified
: x86 Linux
: -- major (vote)
: mozilla1.8rc1
Assigned To: Darin Fisher
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-13 13:48 PDT by Hixie (not reading bugmail)
Modified: 2008-07-31 04:30 PDT (History)
6 users (show)
chase: blocking1.8rc1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch (7.04 KB, patch)
2005-10-20 16:23 PDT, Darin Fisher
benjamin: review+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description Hixie (not reading bugmail) 2005-10-13 13:48:53 PDT
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.
Comment 1 Asa Dotzler [:asa] 2005-10-14 12:44:53 PDT
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?
Comment 2 Nick Thomas [:nthomas] 2005-10-15 03:26:58 PDT
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
Comment 3 Benjamin Smedberg [:bsmedberg] 2005-10-16 06:07:11 PDT
Darin, can you think of a reason why the LD_LIBRARY_PATH would be wrong after
updating?
Comment 4 Darin Fisher 2005-10-19 14:47:28 PDT
No, I can't imagine how that could happen, but it must be happening.
Comment 5 Darin Fisher 2005-10-19 14:49:28 PDT
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 Asa Dotzler [:asa] 2005-10-20 11:34:32 PDT
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.
Comment 7 Scott MacGregor 2005-10-20 14:44:12 PDT
Jay ran into this today too. 
Comment 8 Darin Fisher 2005-10-20 14:49:14 PDT
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 Scott MacGregor 2005-10-20 14:50:43 PDT
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 Jay Patel [:jay] 2005-10-20 14:53:23 PDT
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.
Comment 11 Chase Phillips 2005-10-20 14:56:09 PDT
Jay accidentally set blocking1.8rc1?.  Setting it back to blocking1.8rc1- on his
behalf.
Comment 12 Darin Fisher 2005-10-20 16:17:58 PDT
I have a patch for this.
Comment 13 Darin Fisher 2005-10-20 16:23:19 PDT
Created attachment 200291 [details] [diff] [review]
v1 patch

This implements the solution from comment #8.
Comment 14 Benjamin Smedberg [:bsmedberg] 2005-10-21 08:05:13 PDT
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.
Comment 15 Darin Fisher 2005-10-21 10:28:52 PDT
> 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.
Comment 16 Darin Fisher 2005-10-21 11:29:34 PDT
fixed-on-trunk
Comment 17 Darin Fisher 2005-10-21 11:31:22 PDT
fixed1.8
Comment 18 Chase Phillips 2005-10-24 11:00:46 PDT
Could the patch in this bug have caused bug 313623?
Comment 19 Darin Fisher 2005-10-24 11:09:27 PDT
I don't see an obvious connection other than the check-in times. I'll investigate to see what I can come up with.

Note You need to log in before you can comment on or make changes to this bug.