From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 0ATjOOLcn1+ZHgAA0tVLHw (envelope-from ) for ; Mon, 02 Nov 2020 10:18:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id EOEaNeLcn1/baQAA1q6Kng (envelope-from ) for ; Mon, 02 Nov 2020 10:18:10 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 937619402B0 for ; Mon, 2 Nov 2020 10:18:10 +0000 (UTC) Received: from localhost ([::1]:59730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZWud-0004Lu-Uy for larch@yhetil.org; Mon, 02 Nov 2020 05:18:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZWuF-0004KJ-UX for guix-devel@gnu.org; Mon, 02 Nov 2020 05:17:43 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:42258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZWuD-0000Ak-1z for guix-devel@gnu.org; Mon, 02 Nov 2020 05:17:43 -0500 Received: from localhost (80-110-126-103.cgn.dynamic.surfer.at [80.110.126.103]) by dd26836.kasserver.com (Postfix) with ESMTPSA id B0DFE336560D; Mon, 2 Nov 2020 11:17:35 +0100 (CET) Date: Mon, 2 Nov 2020 11:17:31 +0100 From: Danny Milosavljevic To: Pierre Neidhardt , guix-devel@gnu.org Subject: GNOME in Guix Message-ID: <20201102111731.772e4f7a@scratchpost.org> In-Reply-To: <875z6o19uq.fsf@ambrevar.xyz> References: <20201029203433.2caaa74e@scratchpost.org> <875z6o19uq.fsf@ambrevar.xyz> X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/65RtsheQ7FyBkLXBb7BLMYK"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/02 05:17:36 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.11 X-TUID: EX1hi9yvDQtR --Sig_/65RtsheQ7FyBkLXBb7BLMYK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, On Mon, 02 Nov 2020 08:44:29 +0100 Pierre Neidhardt wrote: > Danny Milosavljevic writes: > > Not much more works yet because I've hit this (design) bug in Guix and/= or GNOME: > > > > * https://github.com/spk121/guile-gi/issues/96 =20 >=20 > Have you tried g-golf? The Nomad browser uses it, it may not suffer > from the aforementioned issue. > Thoughts on that? It really depends on what you mean. If it also uses gobject-introspection,= it will have the same problem. Even gobject-introspection links to glib internally, then registers a class= in that, THEN opens (potentially another) glib at runtime using dlopen in the = same address same. I'm pretty sure that GNOME is not designed for that. If you then use the dlopened glib to use the first-mentioned class, good luck with that. The only reason it didn't fall onto the head of users of other distributions is because those don't support internal dependencies of packages at all--so you always have to update all in lockstep. So the following can only happen in Guix: If a library A has an input Q, and library B has the same input Q, and you use A and B in your program, and then you (guix-) update just B to use Q' (for example a newer version of Q) and recompile your program, then you have both Q and Q' in your process address space! Q is an internal dependency of A, and by coincidence it's an internal dependency of B, too. Just because the internal dependency of B changed shouldn't change the internal depenency of A--that's what "internal" means. Otherwise the modules aren't really modular (because they then don't isolate from each other). I think that the gobject type registry does not consider that it can happen to have to classes with the same class name, registered in respective internal dependencies. The objects of the internal dependency shouldn't be available to the outside program in the first place. That means actually we should propagate a lot of GNOME inputs, which means in practice what a regular user has in his profile will be very much like in other distributions, and internal dependencies will become a weird corner feature nobody uses. Does anyone know how to make dlopen fail on duplicate global variables? I tried to make it fail but I can't get it to work: I tried: File d1.c contains: int x; File d2.c contains: int x; File a.c contains: #include #include // https://stackoverflow.com/questions/43582165/handling-global-variables-i= n-shared-object int main() { if (!dlopen("./d1.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/))= { fprintf(stderr, "dlerror: %s\n", dlerror()); return 1; } if (!dlopen("./d2.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/))= { fprintf(stderr, "dlerror: %s\n", dlerror()); return 2; } return 0; } Then I do: $ gcc -fPIC -shared -Wl,--export-dynamic -o d1.so d1.c $ gcc -fPIC -shared -Wl,--export-dynamic -o d2.so d2.c $ gcc a.c -ldl $ ./a.out $ echo $? 0 --Sig_/65RtsheQ7FyBkLXBb7BLMYK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+f3LsACgkQ5xo1VCww uqVcYgf/Qa3EynIV3h4fgmaqHwI9a8TVXHyklsHEwA3PXhcocIUxWMxayPsZMiq/ WsQP+4RaefGk0rlFawyQl9QV4sKvVlnj979AlSxdI1v/tXYprUUrvedDwtn9RwoQ g3XY2UcS8fWf7KC62BSjCKKXngBB+t+hKFp6wkOdvRooV84MNCQicPR2NBIua1tr L/ixqUBcvUEzRqjvwK4GV2zarz6ZSkGS6KkT3hxclDlPJu00MxaHNHeRCef6PY4z OIsE8nCEh1Ju3UsQCfYVhBowuN8kc7KEPIBAmojwwrpFul39SXbEf5X7U5NU5Ax/ zr1yfFh669Z2/PDWM7H0zQTFpA/vIQ== =Ml50 -----END PGP SIGNATURE----- --Sig_/65RtsheQ7FyBkLXBb7BLMYK--