After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670477 - Extension loading is broken in 3.3.90
Extension loading is broken in 3.3.90
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.3.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-02-20 18:32 UTC by Dimitri
Modified: 2017-04-24 13:14 UTC
See Also:
GNOME target: 3.4
GNOME version: 3.3/3.4


Attachments
Link the gnome-shell binary to libgnome-shell-js.so (1.11 KB, patch)
2012-04-04 21:53 UTC, Owen Taylor
accepted-commit_now Details | Review
patch to ensure link is not removed with --as-needed (1.21 KB, patch)
2012-04-06 18:21 UTC, Alexandre Rostovtsev
reviewed Details | Review
patch to ensure link is not removed with --as-needed (v2) (1.21 KB, patch)
2012-04-06 18:55 UTC, Alexandre Rostovtsev
accepted-commit_now Details | Review

Description Dimitri 2012-02-20 18:32:48 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.
Comment 1 Dimitri 2012-02-24 01:27:10 UTC
The same with 3.3.90
Comment 2 Andreas Proschofsky 2012-03-01 20:10:45 UTC
Same error here on Gentoo
Comment 3 Jasper St. Pierre (not reading bugmail) 2012-03-09 11:53:07 UTC
Is there something with rpath that we need to do here?
Comment 4 Giovanni Campagna 2012-03-09 14:54:51 UTC
(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?
Comment 5 Olav Vitters 2012-03-11 22:41:29 UTC
Does this work somehow on Fedora? Anything we can do to resolve it (packaging or GNOME wise)?
Comment 6 Jasper St. Pierre (not reading bugmail) 2012-03-11 22:46:17 UTC
(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.
Comment 7 Olav Vitters 2012-03-11 22:53:35 UTC
Is there a configure option for that? Or how could someone do that who barely knows ./configure && make && make install? :)
Comment 8 Giovanni Campagna 2012-03-11 23:30:50 UTC
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
Comment 9 Dimitri 2012-03-22 10:40:40 UTC
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?
Comment 10 Giovanni Campagna 2012-03-22 17:57:19 UTC
(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)
Comment 11 l300lvl 2012-03-23 00:39:51 UTC
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.
Comment 12 Jasper St. Pierre (not reading bugmail) 2012-03-26 18:05:17 UTC
Can you post the results of:

 $ objdump -x /usr/bin/gnome-shell | grep RPATH
Comment 13 Andreas Proschofsky 2012-03-27 05:46:12 UTC
That's what I get:

RPATH                /usr/lib64/gnome-bluetooth:/usr/lib64/gnome-shell
Comment 14 Jasper St. Pierre (not reading bugmail) 2012-03-27 07:59:30 UTC
And you can confirm that libgnome-shell-js.so is in /usr/lib64/gnome-shell ?
Comment 15 Andreas Proschofsky 2012-03-27 08:10:18 UTC
(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
Comment 16 Olav Vitters 2012-03-27 08:18:49 UTC
So present on Mageia, Gentoo and opensuse
Comment 17 l300lvl 2012-03-27 15:29:38 UTC
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
Comment 18 Olav Vitters 2012-04-04 20:10:59 UTC
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.
Comment 19 Olav Vitters 2012-04-04 20:13:06 UTC
ah, packager==reporter :)
Comment 20 Dimitri 2012-04-04 20:31:54 UTC
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.
Comment 21 Colin Walters 2012-04-04 21:00:27 UTC
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...
Comment 22 Dimitri 2012-04-04 21:19:06 UTC
Colin - until dlopen() honours DT_RUNPATH of the root executable, this doesn't make any sense, right?
Comment 23 Colin Walters 2012-04-04 21:24:53 UTC
(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.
Comment 24 Colin Walters 2012-04-04 21:32:40 UTC
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.
Comment 25 Owen Taylor 2012-04-04 21:53:02 UTC
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.
Comment 26 Colin Walters 2012-04-04 21:58:40 UTC
(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).
Comment 27 Colin Walters 2012-04-04 22:12:42 UTC
(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.
Comment 28 Dimitri 2012-04-04 22:41:15 UTC
We at Mageia do use "--as-needed", too - the hack didn't work :( Reverted to forcibly switching "--enable-new-dtags" off.
Comment 29 Alexandre Rostovtsev 2012-04-06 18:21:13 UTC
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.
Comment 30 Jasper St. Pierre (not reading bugmail) 2012-04-06 18:27:26 UTC
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?
Comment 31 Alexandre Rostovtsev 2012-04-06 18:30:52 UTC
(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
Comment 32 Jasper St. Pierre (not reading bugmail) 2012-04-06 18:32:31 UTC
Ah, I didn't realize the plugin was part of the shared library.
Comment 33 Alexandre Rostovtsev 2012-04-06 18:36:08 UTC
(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.
Comment 34 Colin Walters 2012-04-06 18:47:17 UTC
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)
{
Comment 35 Alexandre Rostovtsev 2012-04-06 18:55:06 UTC
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.
Comment 36 Jasper St. Pierre (not reading bugmail) 2012-04-06 18:55:56 UTC
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
Comment 37 Dominique Leuenberger 2012-05-02 17:36:09 UTC
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...
Comment 38 Vincent Untz 2012-05-14 12:23:45 UTC
Should this bug be reopened, or are we leaving it as NOTGNOME?
Comment 39 Colin Walters 2012-05-14 13:42:44 UTC
We should apply both patches here.
Comment 40 Colin Walters 2012-05-14 13:43:14 UTC
Review of attachment 211345 [details] [review]:

Yes.
Comment 41 Colin Walters 2012-05-14 13:43:38 UTC
Review of attachment 211501 [details] [review]:

Looks correct.
Comment 42 Jasper St. Pierre (not reading bugmail) 2012-05-18 21:08:56 UTC
Alexandre: do you have a GNOME git account, or do you need somebody to push?
Comment 43 Alexandre Rostovtsev 2012-05-18 22:39:58 UTC
(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).
Comment 44 Olav Vitters 2012-05-19 14:01:33 UTC
(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.
Comment 45 Eternal Sorrow 2016-05-05 04:32:39 UTC
looks like I'm experiensing this bug right now. how is it possible? gentoo, gnome-shell-3.20.1