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.
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
CC'ing startup-foo-master bsmedberg
Darin, can you think of a reason why the LD_LIBRARY_PATH would be wrong after
No, I can't imagine how that could happen, but it must be happening.
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.
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
Jay ran into this today too.
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.
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.
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.
Jay accidentally set blocking1.8rc1?. Setting it back to blocking1.8rc1- on his
I have a patch for this.
Created attachment 200291 [details] [diff] [review]
This implements the solution from comment #8.
Comment on attachment 200291 [details] [diff] [review]
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.
> 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.
Could the patch in this bug have caused bug 313623?
I don't see an obvious connection other than the check-in times. I'll investigate to see what I can come up with.