From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session Date: Wed, 13 Nov 2019 23:02:52 +0100 Message-ID: <87pnhvmo37.fsf@gnu.org> References: <87zhk3tzfn.fsf@netris.org> <87sgpvlj8t.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56068) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iV0k8-0006vp-Tq for bug-guix@gnu.org; Wed, 13 Nov 2019 17:04:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iV0k6-0000id-Oq for bug-guix@gnu.org; Wed, 13 Nov 2019 17:04:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51489) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iV0k6-0000iX-LW for bug-guix@gnu.org; Wed, 13 Nov 2019 17:04:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iV0k6-0001kL-Ex for bug-guix@gnu.org; Wed, 13 Nov 2019 17:04:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87sgpvlj8t.fsf@elephly.net> (Ricardo Wurmus's message of "Tue, 20 Aug 2019 21:38:58 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 37123@debbugs.gnu.org Hello, Ricardo Wurmus skribis: >> Since commit 2b0c755d195c79bfc95cdbe802e1e2dea1adb7a2 in August 2018, >> our 'gnome-shell' executable has been wrapped by a script that sets >> LD_LIBRARY_PATH. >> >> One consequence of this, which I just noticed, is that if 'gnome-shell' >> is based on 'core-updates' (or in my case, 'core-updates-next'), many >> programs based on 'master' will fail to run within the resulting GNOME >> session. > [=E2=80=A6] >> I was unable to easily find an existing bug report tracking this issue, >> so I created this one. > > There was no bug report about this, so thanks for reporting it. I once > brought this issue up on the mailing list here: > > https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00372.html Looking at this bit in the =E2=80=98gnome-shell=E2=80=99 definition: --8<---------------cut here---------------start------------->8--- (wrap-program (string-append out "/bin/gnome-shell") `("GI_TYPELIB_PATH" ":" prefix (,gi-typelib-path)) ;; FIXME: gnome-shell loads these libraries with unqualified ;; names only, so they need to be on LD_LIBRARY_PATH. The ;; alternative might be to patch gnome-shell. `("LD_LIBRARY_PATH" ":" prefix ,(map (lambda (pkg) (string-append (assoc-ref inputs pkg) "/lib")) '("gdk-pixbuf" "gnome-bluetooth" "librsvg" "libgweather")))) --8<---------------cut here---------------end--------------->8--- I checked in Gjs etc. how those imports (e.g., =E2=80=9Cimports.gi.Rsvg=E2= =80=9D in Javascript) are turned into a dlopen. AIUI, this is done by gobject-introspection based on info found in .gir files. In Guix, .gir files contain absolute file names of share libraries. At run-time, =E2=80=98gobject-introspection-absolute-shlib-path.patch=E2=80=99= ensures that dlopen is passed absolute file names. So, IIUC, =E2=80=9Cimports.gi.Rsvg=E2=80=9D should lead to dlopen by absolu= te file name, in which case setting LD_LIBRARY_PATH is useless. However, does anyone know about we can test whether removing the LD_LIBRARY_PATH wrapping above breaks something? Thanks, Ludo=E2=80=99.