gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Asac, can you please comment this? it seems that in karmic, libmozjs.so was in /usr/lib, but is now moved in a private directory. this change horribly breaks gxine

we discourage libmozjs.so use directly. if you need a gecko embedding you need to use the standalone glue to find and load the right path.

gxine has no use for the embedding of geckoes…

On Mon, Mar 22, 2010 at 17:01:28 (CET), Alexander Sack wrote:

> we discourage libmozjs.so use directly.

why? This doesn't seem to be the case in debian.

> if you need a gecko embedding you need to use the standalone glue to
> find and load the right path.

so we need to invent a shell wrapper for gxine that sets LD_LIBRARY_PATH
or compile gxine with rpath because of what reason again?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

> why? This doesn't seem to be the case in debian.

not sure why debian thinks they can maintain this. Mozilla explicitly wants the option to break ABI even in security updates, so when that happens we are screwed. Hence ubuntu doesnt make a top level library out of it.

Mozilla even refused to agree on a small/stable subset API ... so there is no way to do what debian does without calling for troubles.

> so we need to invent a shell wrapper for gxine that sets LD_LIBRARY_PATH
> or compile gxine with rpath because of what reason again?

yes. use /usr/lib/xulrunner-`xulrunner-1.9.2 --gre-version` to get the right LD_LIBRARY_PATH; dont use rpath because of the various reasons - one the one from above - we intentionally don't ship a stable directory name in minor updates.

so yes, LD_LIBRARY_PATH basically causes the same, but at least i warned folks because they dont know how to do that without talking to me. So doing this is at maintainers risk. Basically, for main, you should be willing to swiflty fix your code to support new ABI if we need to roll out such a security update. For universe the same, though I try to not think about it ;)

To do this properly, I need a patch (touching configure.ac and relevant Makefile.am) which looks to see if the relevant xulrunner-$VERSION exists (presumably using path and version information extracted via pkg-config, truncating the version no. to three components if needed) and, if it does, causes a suitable shell script to be installed. (BTW, I see no /usr/lib/xulrunner-* which isn't a directory… hmm, /usr/lib/xulrunner-$VERSION/run-mozilla.sh?)

Anyway, I see no need for all this hassle with LD_LIBRARY_PATH and xulrunner; surely, if an backward-incompatible ABI change is made then the library's soname is bumped accordingly, security update or not, and it can live in /usr/lib without causing any problems. I don't see what's unmaintainable about that.

Any fixes which may be required due to ABI changes shouldn't pose a problem.

Darren,

The issue is though that libmozjs is not versioned at all (so there is no so name and any ABI change wil break everything linked against it). This is why we make it hard to use libmozjs directly by installing it to a path that isn't stable across minor versions

Can we just add a wrapper around gxine like I did for edbrowse? I'd be happy to do this for an SRU.

A wrapper would be fine; preferably (from my POV) in a form which can be committed upstream.

Same error:
gxine: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Assigning to myself, probably will not get to until next month though.

@micahg, I've now prepared a patch and pushed a branch. do you want to have a look at it or shall I upload to lucid-proposed straight away?

Reassigning to siretart as he's doing the work for this.

Wrapper looks fine to me.

This seems to be in lucid-proposed unapproved queue

Please attach a debdiff and a Test Case comment.

Subscribed ubuntu-sru so they can approve

diff can be seen here:

https://code.edge.launchpad.net/~siretart/gxine/bug.542506/+merge/25976

please accept for lucid-proposed and copy to maverick.

There was a similar bug in Gutsy/Feisty: bug#130218. There recently a nice gxine-hack.sh script has been posted (see post #13) - requires Firefox being installed, but then it always grabs the latest version.

Reinhard Tartler: I understand you already have a wrapper script, looking for the xulrunner library - maybe it would be advantageous to add the logic to find the most recent Firefox library if that fails?

On Do, Mai 27, 2010 at 20:40:13 (CEST), h1repp wrote:

> Reinhard Tartler: I understand you already have a wrapper script,
> looking for the xulrunner library - maybe it would be advantageous to
> add the logic to find the most recent Firefox library if that fails?

I don't think so. are you sure that this would work at all? and
moreover, under what conditions would the xulrunner libmozjs.so not work
for gxine?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Accepted gxine into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

gxine starts up fine now. Thanks!

Yes, but that's about it. Luckily gxine is not the default movie player; it is so buggy I don't bother reporting about it anymore. I do better with VLC and totem; kaffeine is (or at least used to be) the best for DVB, and xine(-ui) for DVD.

If you can't be bothered to report and, ideally, help fix bugs (ideally, submit patches UPSTREAM or ensure that they get forwarded), don't be surprised if some remain unfixed. (About your DVD issue: there shouldn't be much difference between gxine and xine-ui here, given that the bulk of it is xine-lib, libdvdread and libdvdnav.)

And this particular isue still needs to be resolved upstream. Not having a convenient Ubuntu installation, I won't be fixing it, and I can guarantee that patches which break things on Debian systems will be rejected :-)

Hi,

I've tried the proposed gxine :
$ dpkg -l gxine | grep ii
ii gxine 0.5.904-2ubuntu3.1 the xine video player, GTK+/Gnome user interface

And I didn't had the bug when playing an mp3 file.

Great work, thanks a lot!

This bug was fixed in the package gxine - 0.5.904-2ubuntu3.1

---------------
gxine (0.5.904-2ubuntu3.1) lucid-proposed; urgency=low

  * Enable gxine to find and load libmozjs.so by installing wrapper that
    sets LD_LIBRARY_PATH. Fixes LP: #542506
 -- Reinhard Tartler <email address hidden> Mon, 24 May 2010 18:32:54 +0200

Copied to maverick.