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 768781 - Build failure: private mutter libs not found
Build failure: private mutter libs not found
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 781527 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-07-13 16:09 UTC by Dominique Leuenberger
Modified: 2021-07-05 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix the linking by adding the orrect rpath (1.69 KB, patch)
2016-07-13 16:09 UTC, Dominique Leuenberger
none Details | Review
Nits fixed (1.68 KB, patch)
2016-07-13 16:20 UTC, Dominique Leuenberger
none Details | Review
(really fixed) (1.68 KB, patch)
2016-07-13 16:24 UTC, Dominique Leuenberger
none Details | Review
Alternative patch (2.97 KB, patch)
2016-08-30 09:55 UTC, Dominique Leuenberger
none Details | Review
Option 3 (2.80 KB, patch)
2016-08-30 10:06 UTC, Dominique Leuenberger
none 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 (2.96 KB, patch)
2017-04-24 09:35 UTC, Iain Lane
none Details | Review

Description Dominique Leuenberger 2016-07-13 16:09:19 UTC
Build aborted with:

/home/abuild/rpmbuild/BUILD/gnome-shell-3.21.3/src/tmp-introspectWlcqvs/.libs/ShellMenu-0.1: error while loading shared libraries: libmutter-clutter-1.0.so: cannot open shared object file: No such file or directory
Comment 1 Dominique Leuenberger 2016-07-13 16:09:53 UTC
Created attachment 331431 [details] [review]
Fix the linking by adding the orrect rpath
Comment 2 Florian Müllner 2016-07-13 16:15:59 UTC
Review of attachment 331431 [details] [review]:

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

Also typo: nescessary
Comment 3 Dominique Leuenberger 2016-07-13 16:20:46 UTC
Created attachment 331432 [details] [review]
Nits fixed
Comment 4 Dominique Leuenberger 2016-07-13 16:24:15 UTC
Created attachment 331433 [details] [review]
(really fixed)
Comment 5 Dominique Leuenberger 2016-08-22 08:41:22 UTC
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?
Comment 6 Ray Strode [halfline] 2016-08-29 17:54:31 UTC
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)
Comment 7 Dominique Leuenberger 2016-08-30 09:55:35 UTC
Created attachment 334423 [details] [review]
Alternative patch

you mean something like that?
Comment 8 Dominique Leuenberger 2016-08-30 09:56:14 UTC
(the removal of gnome_shell_LDFLAGS, gnome_shell_extension_prefs_LDFLAGS gnome_shell_portal_helper_LDFLAGS would still need to be checked though)
Comment 9 Dominique Leuenberger 2016-08-30 10:05:39 UTC
(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...
Comment 10 Dominique Leuenberger 2016-08-30 10:06:27 UTC
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
Comment 11 Dominique Leuenberger 2016-08-30 10:11:46 UTC
(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)
Comment 12 Jura 2016-09-21 12:25:45 UTC
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
Comment 13 Jura 2016-09-21 12:27:54 UTC
I add «export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/mutter» to /usr/bin/gnome-session and gdm start successful
Comment 14 Dominique Leuenberger 2017-03-14 17:45:00 UTC
I'm somewhat surprised nobody else is hitting this issue... or the reactions would be much bigger
Comment 15 Florian Müllner 2017-04-20 17:35:16 UTC
(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?
Comment 16 Florian Müllner 2017-04-20 17:35:41 UTC
*** Bug 781527 has been marked as a duplicate of this bug. ***
Comment 17 Iain Lane 2017-04-24 09:35:25 UTC
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.
Comment 18 Olav Vitters 2017-04-24 13:14:33 UTC
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.
Comment 19 Dominique Leuenberger 2017-04-24 13:18:55 UTC
(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
Comment 20 GNOME Infrastructure Team 2021-07-05 14:04:32 UTC
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.