Created attachment 331431 [details] [review]
Fix the linking by adding the orrect rpath

Review of attachment 331431 [details] [review]:

Style nit:
"build: Add" instead of "Build: add"

Also typo: nescessary

Created attachment 331432 [details] [review]
Nits fixed

Created attachment 331433 [details] [review]
(really fixed)

We still carry this patch - and it is still necessary for 3.21.90. Any chance to get it merged before 3.22.0 hits the shelves?

Review of attachment 331433 [details] [review]:

::: src/Makefile.am
@@ +322,3 @@
 	$(NULL)
 
+libgnome_shell_menu_la_LDFLAGS = $(libgnome_shell_ldflags) -R$(MUTTER_TYPELIB_DIR)

So throughout the file -rpath is used, not -R.  They should be equivalent, but better to be consistent!

@@ +329,3 @@
 libgnome_shell_base_la_CPPFLAGS = $(gnome_shell_cflags)
 
+libgnome_shell_la_LDFLAGS = $(libgnome_shell_ldflags) -R$(MUTTER_TYPELIB_DIR)

If you put this in libgnome_shell_ldflags definition, then you wouldn't have to write it twice.

Also, once this goes in, can:

gnome_shell_LDFLAGS
gnome_shell_extension_prefs_LDFLAGS gnome_shell_portal_helper_LDFLAGS

get removed? They'd just be doing redundant work then, right? (i don't really know)

Created attachment 334423 [details] [review]
Alternative patch

you mean something like that?

(the removal of gnome_shell_LDFLAGS, gnome_shell_extension_prefs_LDFLAGS gnome_shell_portal_helper_LDFLAGS would still need to be checked though)

(In reply to Ray Strode [halfline] from comment #6)
> Also, once this goes in, can:
> 
> gnome_shell_LDFLAGS
> gnome_shell_extension_prefs_LDFLAGS gnome_shell_portal_helper_LDFLAGS
> 
> get removed? They'd just be doing redundant work then, right? (i don't
> really know)

Indeed, they seem to be removable, as libgnome-shell.la now brings -R$(MUTTER_TYPELIB_DIR)

all of above mentioned libs have libgnome-shell.la added via LDADD; I have a 3rd path option with this cleaned out as well...

Created attachment 334424 [details] [review]
Option 3

This patch cleans out some of the redundancies in plus - tested this patch while building an RPM for openSUSE

(before the question comes: -rpath is not an option, as libtool will strip it on subsequent .la files for its own rpath. The only valid option is -R)

After apply «Option 3» compile successful, but gdm show black screen.
In journaldctl: 
org.gnome.Shell.desktop[24529]: /usr/bin/gnome-shell: error while loading shared libraries: libmutter-cogl-pango.so: cannot open

I add «export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/mutter» to /usr/bin/gnome-session and gdm start successful

I'm somewhat surprised nobody else is hitting this issue... or the reactions would be much bigger

(In reply to Dominique Leuenberger from comment #14)
> I'm somewhat surprised nobody else is hitting this issue... or the reactions
> would be much bigger

Maybe you are being hit by bug 777519?

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

Created attachment 350286 [details] [review]
OK, since we have a similar thing with Ubuntu's default compiler flags & my bug got (correctly) duped to this one, I took a look at the patch. I think that people on other distros might be able to reproduce this by building with -Wl,--enable-new-dtags in 

gnome-shell wouldn't launch with the latest patch (Attachment 334424 [details]), with this error:

  org.gnome.Shell.desktop[1523]: /usr/bin/gnome-shell: error while loading shared libraries: libmutter-cogl-pango-0.so: cannot open shared object file: No such file or directory

so I believe the -R setting needs to be kept for gnome-shell the binary. The attached patch does that - please review.

---

build: Move rpath on mutter's private library directory to libgnome-shell

The build may fail with:

  [...]/src/tmp-introspectodvrhpz5/.libs/Shell-0.1: error while loading
  shared libraries: libmutter-clutter-0.so: cannot open shared object
  file: No such file or directory

because of missing RPATH/RUNPATH on some libraries meaning the dynamic
linker can't find libmutter-clutter-N.so.

Pass this to LDFLAGS so that it's added and found.

(-R is needed rather than -rpath because there's already a -rpath passed
in by automake and we get "libtool: link: warning: ignoring multiple
`-rpath's for a libtool library". Tip from
https://lists.gnu.org/archive/html/libtool/2008-11/msg00008.html.)

Modified by Iain Lane <iain.lane@canonical.com>: Keep -R for
$(bindir)/gnome-shell itself; required for gnome-shell to start up.

The rpath discussion reminds me of bug 670477. In Mageia we have the following in the gnome-shell spec:

# 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


Not sure if this bug is related.

(In reply to Olav Vitters from comment #18)
> The rpath discussion reminds me of bug 670477. In Mageia we have the
> following in the gnome-shell spec:
> 
> # 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
> 
> 
> Not sure if this bug is related.

Sounds related, yes.. with the patch proposed here you'd no longer have to disable the new_dtags format

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.