GNOME Bugzilla – Bug 670477
Extension loading is broken in 3.3.90
Last modified: 2017-04-24 13:14:33 UTC
After upgrade to 3.3.5, extensions do not load anymore. Yep, there are only few extensions compatible with 3.3.5 now (four at ext-g-o plus "Hello world"), but even those fail with the following message in Looking Glass: Extension "Hello_World@localhost" had error: Error: Could not locate shell_js_add_extension_importer: libgnome-shell-js.so: cannot open shared object file: No such file or directory Additionally, the following is printed to console: Window manager warning: Log level 16: Failed to load shared library 'libgnome-shell-js.so' referenced by the typelib: libgnome-shell-js.so: cannot open shared object file: No such file or directory That libgnome-shell-js.so file is installed at /usr/lib/gnome-shell (together with the accompanying ShellJS-0.1.typelib). If I symlink libgnome-shell-js.so to /usr/lib, extensions start to load again. I'm using Linux Mageia 2, a very young distro. The gnome-shell package is almost vanilla, with insignificant patches. GJS is 1.31.10. If anyone suspects a packaging error, I'll appreciate any considerations on how to detect and fix it.
The same with 3.3.90
Same error here on Gentoo
Is there something with rpath that we need to do here?
(In reply to comment #3) > Is there something with rpath that we need to do here? man dlopen says that the only rpath looked for is the one in the binary, and that includes gnome-shell's pkglibdir. Could it be a packaging problem or glibc/binutils/libtool incompatibility?
Does this work somehow on Fedora? Anything we can do to resolve it (packaging or GNOME wise)?
(In reply to comment #5) > Does this work somehow on Fedora? Anything we can do to resolve it (packaging > or GNOME wise)? Make sure that the gnome-shell binary has the correct rpath.
Is there a configure option for that? Or how could someone do that who barely knows ./configure && make && make install? :)
It works in Fedora 16 + jhbuild, and I just checked Fedora 17 works too. For the record, Fedora 16: binutils-2.21.53.0.1-6.fc16.x86_64 (gold, not ld.bfd) glibc-2.14.90-24.fc16.6.x86_64 DT_RPATH for gnome-shell-real is /opt/gnome/lib64/gnome-bluetooth:/opt/gnome/lib64/gnome-shell Fedora 17: binutils-2.22.52.0.1-5.fc17.x86_64 (ld.bfd, I believe) glibc-2.15-23.fc17.x86_64 DT_RPATH for gnome-shell is /usr/lib64/gnome-shell:/usr/lib64/gnome-bluetooth Forcing a specific rpath should not be needed, and libtool should do the magic out-of-box (jhbuild has no special libtool handling, and yet works even in a non-system prefix). Unfortunately, it is common to patch libtool and binutils in a distro specific way these days (for example, the debian libtool ignores depenency_libs). In any case, there is a tool called chrpath that can be used to replace the DT_RPATH tag of the binary with the correct value. You should run it after installing the binary; see the way fedora does at http://pkgs.fedoraproject.org/gitweb/?p=gnome-shell.git;a=blob;f=gnome-shell.spec;h=145bb638902ae37f9205b5b1e3ed0f8d45119164;hb=refs/heads/f17#l112
Guys with Fedora, could you please show us RPATH for /usr/lib/gnome-shell/libgnome-shell.so? Does it contain "/usr/lib/gnome-shell" directory?
(In reply to comment #9) > Guys with Fedora, could you please show us RPATH for > /usr/lib/gnome-shell/libgnome-shell.so? Does it contain "/usr/lib/gnome-shell" > directory? No, only /usr/lib64/gnome-bluetooth. (I also checked, libgnome-shell-js.so is not needed for either libgnome-shell.so or gnome-shell, in case it was an --as-needed problem)
Just felt need to report this is also present on Suse 12.2 Milestone 2, GS 3.3.90. Is there any way to resolve this yet for testing? I tried symlinking but it didn't seem to work, I am very happy to try again.
Can you post the results of: $ objdump -x /usr/bin/gnome-shell | grep RPATH
That's what I get: RPATH /usr/lib64/gnome-bluetooth:/usr/lib64/gnome-shell
And you can confirm that libgnome-shell-js.so is in /usr/lib64/gnome-shell ?
(In reply to comment #14) > And you can confirm that libgnome-shell-js.so is in /usr/lib64/gnome-shell ? Absolutely: /usr/lib64/gnome-shell/libgnome-shell-js.so
So present on Mageia, Gentoo and opensuse
same for openSUSE 12.2 m2 # objdump -x /usr/bin/gnome-shell | grep RPATH RPATH /usr/lib64/gnome-bluetooth:/usr/lib64/gnome-shell and not that it helps but # file /usr/lib64/gnome-shell/libgnome-shell-js.so /usr/lib64/gnome-shell/libgnome-shell-js.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xa5217b1b1291ecada5c2fcff5d554e4ca08273e8, stripped
this is what a Mageia packager just added to the gnome-shell spec file: # To make GNOME Shell extensions load, we need to get rid of DT_RUNPATH on /usr/bin/gnome-shell # (see glibc bug #13945, GNOME bug #670477, Mageia bug #4523) %define _disable_ld_enable_new_dtags 1 I haven't tested this yet.
ah, packager==reporter :)
Due to DT_RUNPATH non-transitive behaviour, the gnome-shell binary needs to be built with DT_RPATH tag only. The presence of DT_RUNPATH tag will prevent GNOME Shell from loading GModules from non-standard path (namely, libgnome-shell-js.so from /usr/lib*/gnome-shell). Please make sure that the binary is not linked with the "--enable-new-dtags" linker flag. In Mageia, we have a special RPM variable for that. See http://sourceware.org/bugzilla/show_bug.cgi?id=13945 for further info.
This is a very complicated issue. http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ Has some useful information too. Let me cut to the chase though and say the final result that we really want after building gnome-shell is that the bin/gnome-shell executable has a RUNPATH for /usr/lib/gnome-shell AND NOTHING ELSE. The problem is that to implement this, we'd have to sidestep libtool and directly run the linker to ensure we pass --enable-new-dtags (so we get RUNPATH instead of RPATH) as well as to ensure we're NOT creating a RUNPATH or RPATH for system library directories (which libtool currently does because...well, it's a bug). Possibly we could import a copy of chrpath and do the requisite surgery after building, but before installing, but that's got its own level of gross. "Distributions" are somewhat at fault here in that they're too cavalier with access to default linker flags. These things should be carefully maintained in upstream - having different random defaults across distributions is incredibly poisonous to the ecosystem. Transitioning to RUNPATH (so that LD_LIBRARY_PATH allows overriding) makes sense - but it should probably be done by changing specific modules to opt-in va libtool API. Again - bottom line: If someone were to make a patch to sidestep libtool/distribution linker defaults and generate the Right Thing (an executable with RUNPATH for $libdir/gnome-shell out of the box upstream), I'd love to review that patch. Failing that, we can flail around in spec files...
Colin - until dlopen() honours DT_RUNPATH of the root executable, this doesn't make any sense, right?
(In reply to comment #22) > Colin - until dlopen() honours DT_RUNPATH of the root executable, this doesn't > make any sense, right? Yes, you're right; my bad. I had gotten it in too far into my head that the difference between DT_RPATH and DT_RUNPATH is simply one of the precedence of LD_LIBRARY_PATH, but Roland explicitly negated that here: http://sourceware.org/ml/libc-hacker/2002-11/msg00011.html So perhaps then, given the current state of things, what we want is a gnome-shell binary which has an RPATH for /usr/lib/gnome-shell (and again, nothing else, particularly *not* the system library search paths). Again, unfortunately I'm not aware of a way to coerce the combination of (libtool+distro linker defaults) into doing this; we'd have to either run the linker directly or modify the result after building. Passing --disable-new-dtags (or just not passing --enable-new-dtags) in the spec file as you have it is almost what's desired except for the libtool bug that includes system library paths, which breaks the nvidia extension's desire to ship its own libGL.so.
Note when he says "The application or library can use whatever prefix it put in its DT_RUNPATH on the strings it passes to dlopen directly." - he's not wrong in that we *could* do that - we could teach the typelib compiler to inject an *absolute* path based on the prefix into the generated typelib. We couldn't easily use Makefile.introspection inside src/Makefile.am anymore (at least for ShellJS-1.0.gir/typelib), but it would be a matter of doing: g-ir-compiler -l $(libdir)/libgnome-shell-js.so -o ShellJS-1.0.typelib ShellJS-1.0.gir Where $(libdir) is an absolute path. Then we'd be passing that to dlopen() when the .typelib is loaded.
Created attachment 211345 [details] [review] Link the gnome-shell binary to libgnome-shell-js.so The fact that the Shell typelib loads properly but the ShellJS one doesn't implies that the attached patch will make things work with --enable-new-dtags. I haven't tested. ==== Depending on the exact linker options and versions, rpath's written into the binary may, or may not, be honored by dlopen(). Work around this by simply linking the gnome-shell binary to gnome-shell-js, since then dlopen() doesn't need to search paths.
(In reply to comment #25) > Created an attachment (id=211345) [details] [review] > Link the gnome-shell binary to libgnome-shell-js.so > > The fact that the Shell typelib loads properly but the ShellJS one doesn't > implies that the attached patch will make things work with > --enable-new-dtags. I haven't tested. Oh, clever. If Dimitri confirms it works, then count it as accepted-commit-now by me. (I still want a way to avoid libtool generating system rpaths in the upstream build system, but that's a separate issue, and doesn't affect only gnome-shell).
(In reply to comment #26) > (In reply to comment #25) > > Created an attachment (id=211345) [details] [review] [details] [review] > > Link the gnome-shell binary to libgnome-shell-js.so > > > > The fact that the Shell typelib loads properly but the ShellJS one doesn't > > implies that the attached patch will make things work with > > --enable-new-dtags. I haven't tested. > > Oh, clever. If Dimitri confirms it works, then count it as accepted-commit-now > by me. There is one thing - this hack will be undone by people who use --as-needed in the default linker flags, because libgnome-shell-js.so isn't satisfying any dependency of gnome-shell. Practically speaking I think at least Debian uses (or has experimented with) --as-needed.
We at Mageia do use "--as-needed", too - the hack didn't work :( Reverted to forcibly switching "--enable-new-dtags" off.
Created attachment 211499 [details] [review] patch to ensure link is not removed with --as-needed This patch (needs to be applied after the one in Comment 25) adds a dummy call from main.c into shell-js.c's shell_js_add_extension_importer(), ensuring that the link from /usr/bin/gnome-shell to libgnome-shell-js.so is not removed when using -Wl,--as-needed. Works fine on Gentoo.
Review of attachment 211499 [details] [review]: We already have a very similar hack in gnome-shell-plugin.c, so why not put it in there, and make it match the other?
(In reply to comment #30) > Review of attachment 211499 [details] [review]: > > We already have a very similar hack in gnome-shell-plugin.c, so why not put it > in there, and make it match the other? Because that results in libtool: link: gcc -o /var/tmp/portage/gnome-base/gnome-shell-3.4.0/work/gnome-shell-3.4.0/src/tmp-introspectkrGxju/Gvc-1.0 -march=native -O2 -pipe -ggdb -Wall -Wmissing-prototypes /var/tmp/portage/gnome-base/gnome-shell-3.4.0/work/gnome-shell-3.4.0/src/tmp-introspectkrGxju/Gvc-1.0.o -pthread -Wl,--export-dynamic -Wl,--export-dynamic -L. ./.libs/libgvc.a -lpulse-mainloop-glib -lpulse -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -pthread ./.libs/libgnome-shell.so: undefined reference to `shell_js_add_extension_importer' collect2: ld returned 1 exit status make[3]: *** [run-js-test] Error 1
Ah, I didn't realize the plugin was part of the shared library.
(In reply to comment #30) > Review of attachment 211499 [details] [review]: > > We already have a very similar hack in gnome-shell-plugin.c, so why not put it > in there, and make it match the other? Also, because DT_RUNPATH is non-transitive, so linking libgnome-shell.so to libgnome-shell-js.so (gnome-shell-plugin.c is part of libgnome-shell, not the gnome-shell executable) without linking /usr/bin/gnome-shell directly to libgnome-shell-js.so will presumably still result in /usr/bin/gnome-shell failing to load extensions.
Review of attachment 211499 [details] [review]: A style comment...this is probably the best we can do until we patch libtool. ::: src/main.c @@ +352,3 @@ +*/ + +void _shell_link_to_shell_js(void) { Look at the rest of the source code, you can clearly see that's not our coding style. It should be: void _shell_link_to_shell_js (void) {
Created attachment 211501 [details] [review] patch to ensure link is not removed with --as-needed (v2) (In reply to comment #34) > Look at the rest of the source code, you can clearly see that's not our coding > style. It should be: > > void > _shell_link_to_shell_js (void) > { You are right. Fixed.
Review of attachment 211499 [details] [review]: Colin, we already use this style here: http://git.gnome.org/browse/gnome-shell/tree/src/gnome-shell-plugin.c#n382 If you want to fix the bad style there, go ahead. I'll also point out that you ACN'd the patch with the bad style: https://bugzilla.gnome.org/show_bug.cgi?id=639324
The combination of attachment 211345 [details] [review] and attachment 211501 [details] [review] resolves the issue on openSUSE. Agreed, not a nice solution, but better than no extensions at all. *** Some random blubber from me... this might all be wrong or not... ***: Some more info to the issue: /usr/bin/gnome-shell on openSUSE has RPATH and RUNPATH both set to: /usr/lib64/gnome-shell:/usr/lib64/gnome-bluetooth BUT: libgnome-shell-js is not dlopen'ed by gnome-shell, so this is useless. My first misleading idea was to check /usr/lib64/gnome-shell/libgnome-shell.so, which only had /usr/lib64/gnome-bluetooth listed in RUNPATH and RPATH, adding the right ones though did not help. Again: libgnome-shell never initiates the dlopen. As this is introspection based, obviously, the dlopen is executed by libgirepository-1.0.so.0, one which surely must not be thought on how to find this lib...
Should this bug be reopened, or are we leaving it as NOTGNOME?
We should apply both patches here.
Review of attachment 211345 [details] [review]: Yes.
Review of attachment 211501 [details] [review]: Looks correct.
Alexandre: do you have a GNOME git account, or do you need somebody to push?
(In reply to comment #42) > Alexandre: do you have a GNOME git account, or do you need somebody to push? I recently got a git account. Sorry, I did not realize that you expected me to do the committing :) Pushed both patches to master at http://git.gnome.org/browse/gnome-shell/commit/?id=e20ea19f34a4ef9661c3cece2793c0c7f5d3dca9 and http://git.gnome.org/browse/gnome-shell/commit/?id=3c81e9f0e7e06d77528643c749868f7524f572b0 Pushed both patches to gnome-3-4 branch at http://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-4&id=4cf79088a5abc1777487470c941cfa484b5d1159 and http://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-4&id=ecb9c881beaa5a772df506eea829256c4db91124 The bug can now be marked closed (I do not have the permission bits to change its status).
(In reply to comment #43) > The bug can now be marked closed (I do not have the permission bits to change > its status). You should really either have/ask for bugzilla permissions before you ask for git permissions. We hand out bugzilla permissions like candy.
looks like I'm experiensing this bug right now. how is it possible? gentoo, gnome-shell-3.20.1