Created attachment 129668 [details] [review]
Work around Ubuntu xulrunner bug in the same way our .jhbuildrc does

*** Bug 574499 has been marked as a duplicate of this bug. ***

Hi, 
I tried the patch (using git apply command) but the result is the same, with this as the output:

jaybee@laptop:~/gnome-shell/source/gnome-shell/src$ ./gnome-shell --replace
Window manager warning: Log level 16: Could not load library [/home/jaybee/gnome-shell/source/gnome-shell/src/libgnome-shell.la (libmozjs.so: cannot open shared object file: No such file or directory)]
Window manager warning: Log level 8: failed to load plugins

I am using Ubuntu Jaunty and this is the output of locate libmozjs.so
/usr/lib/xulrunner-1.9.0.7/libmozjs.so
/usr/lib/xulrunner-devel-1.9.0.7/sdk/lib/libmozjs.so

oh, you have to do

    jhbuild buildone -n -f -a gnome-shell

after applying it, to regenerate src/gnome-shell from src/gnome-shell.in. Does that help?

Thanks, it works now as expected!

committed

is src/gnome-shell.in something used at build time? otherwise, this patch seems wrong, because the .pc files you rely on are shipped by the xulrunner-dev package which isnt available except on development systems.

If you want to keep the LD_LIBRARY_PATH approach, consider to use 

/usr/lib/xulrunner-`xulrunner --gre-version`

to find the proper path.

we should be running pkg-config at build time and substituting the result in

Created attachment 134058 [details] [review]
Do the workaround for Ubuntu xulrunner breakage at build time

Can you verify that this patch fixes things?

Created attachment 137710 [details] [review]
buildtime fix - set LD_LIBRARY_PATH properly for gir scanner runs

Created attachment 137712 [details] [review]
set LD_LIBRARY_PATH for runtime

(In reply to comment #9)
> Created an attachment (id=134058) [edit]
> Do the workaround for Ubuntu xulrunner breakage at build time
> 
> Can you verify that this patch fixes things?
> 

Your patch would require a rebuild whenever xulrunner gets updated from lets say 1.9.0.11 to 1.9.0.12. The buildtime and runtime patches attached should do the right thing. If you have problems on other distros let me know.

the changes from alexander fix the build issue on karmic

the patch from comment #11 fails on Mandriva Cooker:
xulrunner --xre-version

Better to hard-code the xulrunner path at build time.

Review of attachment 137712 [details] [review]:

It is wrong to hard-code /usr/lib/xulrunner-something, as on x86_64 this would be /usr/lib64/xulrunner-something.

Review of attachment 134058 [details] [review]:

While this is theoretically right, I think this is going to result in a lot of problems with packages getting out of sync on Firefox security updates. Practically speaking libmozjs has been very compatible across minor version updates.

Review of attachment 137710 [details] [review]:

This part of the Makefile.am is already ugly enough without injecting this workaround here, this can be worked by setting LD_LIBRARY_PATH in the Debian packaging for the build.

Review of attachment 137712 [details] [review]:

I think this is basically the right approach. Possible fixes for the problem Götz mentions:

 1) You could effectively do 'xulrunner --find-gre `xulrunner --gre-version`' and then strip off the last component from that

 2) You could borrow the code from jhbuild that choses /usr/lib64 vs. /usr/lib

try:
    uname = os.uname()
    use_lib64 = (uname[0], uname[4]) in [ ('Linux', 'x86_64'),
                                          ('Linux', 'ppc64'),
                                          ('Linux', 's390x') ]
    del uname
except AttributeError:
    # some platforms don't have os.uname (ie. Win32)
    use_lib64 = False

 3) You could just search /usr/lib64/xulrunner-<version>, /usr/lib/xulrunner-<version> and use the first that you fine

I think I like 3) best because it's going to be the least code.

libmozjs is not something that should be used. upstrema explicity wants to not maintain a stable API/ABI ... even in security updates (they rarely break it, but when asking if we can make this a policy you get "we want to be able to break abii/api).

So really, please move away from mozjs

Since we cannot move away from mozjs (because we use GJS code in libgnome-shell, and because we routinely use JS 1.6 / JS 1.7 features like let and destructuring assignment, so moving to seed would be nontrivial), and given that libmozjs do longer uses a pkg-config hack, instead setting RPATH at build time, I'm marking this RESOLVED FIXED.