(In reply to comment #0)
> Created an attachment (id=184154) [details] [review]
> Artificial dependency to force ld to link libgnome-bluetooth-applet.so into
> gnome-shell
> 
> The patch from bug 639324 to add an artificial dependency on
> libgnome-bluetooth-applet.so to prevent ld from dropping it with --as-needed is
> still needed even after the move to a single binary gnome-shell.
> 
> b6749f4b: BluetoothStatus: depend more on libgnome-bluetooth-applet
> 
> The hack just needs to move from src/gnome-shell-plugin.c to src/main.c
> 
> This is needed at least on Gentoo, Arch Linux, and OpenSUSE (although Arch
> Linux has decided to add /usr/lib/gnome-bluetooth to LD_LIBRARY_PATH so they
> can make gnome-bluetooth an optional runtime dependency)

That patch was merged, and libgnome-shell.so depends on libgnome-bluetooth-applet, so should load it, before any code (JS or C) is run. Moving the HACK should not be needed.

(In reply to comment #1)
> That patch was merged, and libgnome-shell.so depends on
> libgnome-bluetooth-applet, so should load it, before any code (JS or C) is run.
> Moving the HACK should not be needed.

That would be true, if the hack were still there. During the move to gnome-shell, the hack was (accidentally?) removed, so it now needs to be re-added. Sorry for not being clear about this.

History verified, original patch which still applied fine resurrected and re-pushed.

reopening: the code is not needed, and is now creating "can't find libgnome-bluetooth-applet.so" errors in some situations when compiling the typelib.

We were mistakenly still linking the library into gnome-shell even after removing the code that used it. I'm guessing Nirbheek just saw ld giving an error about dropping the unused dependency and then filed this bug. If there is some other problem (eg, GnomeBluetoothApplet not being importable on some platforms), then that would be a girepository bug.

Created attachment 190309 [details] [review]
Revert "BluetoothStatus: depend more on libgnome-bluetooth-applet"

This reverts commit c1ba920c86edb1f1530d031d53985e5b84c294cb.

The depend-on-libgnome-bluetooth-applet code was not removed
accidentally, it was removed intentionally: we call
g_irepository_prepend_search_path() on $(BLUETOOTH_DIR), so we can
just open libgnome-bluetooth-applet.so at runtime just like any other
library.

Created attachment 190310 [details] [review]
gnome-shell: don't link against libgnome-bluetooth-applet

Even after removing the code that *used* libgnome-bluetooth-applet,
we were still accidentally linking against it. Fix that.

Review of attachment 190309 [details] [review]:

Calling g_irepository_prepend_search_path() doesn't add to e.g. LD_LIBRARY_PATH, so the commit message is somewhat misleading.  How about:
s,\.so,.typelib,
s/library/typelib/

Review of attachment 190310 [details] [review]:

Squash with previous commit?

(In reply to comment #7)
> Review of attachment 190309 [details] [review]:
> 
> Calling g_irepository_prepend_search_path() doesn't add to e.g.
> LD_LIBRARY_PATH, so the commit message is somewhat misleading.  How about:
> s,\.so,.typelib,
> s/library/typelib/

Not only it is misleading, it will reintroduce the bug. There is no way to load $(libdir)/gnome-bluetooth/libgnome-bluetooth-applet.so, unless you add that position to LD_LIBRARY_PATH or ld.so.conf.d.

(In reply to comment #7)
> Calling g_irepository_prepend_search_path() doesn't add to e.g.
> LD_LIBRARY_PATH, so the commit message is somewhat misleading.

hm... and also, the patch doesn't work... but apparently you have to debugexit and start the shell again to see it fail; it you just restart, it somehow magically continues to be able to find libgnome-bluetooth-applet.so even though it's not linked against it... that must be why I thought it was safe to remove last time too?

OK, I'm going to close this again and try to figure out what's going wrong with linking on this machine...