unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Danny Milosavljevic <dannym@scratchpost.org>, ludo@gnu.org
Cc: guix-devel@gnu.org
Subject: Re: GNOME in Guix
Date: Wed, 04 Nov 2020 10:45:06 +0100	[thread overview]
Message-ID: <6ea08f910493be04f088db1ac6b98b1ecbd6d968.camel@student.tugraz.at> (raw)
In-Reply-To: <20201104090815.05654315@scratchpost.org>

Hi,
Am Mittwoch, den 04.11.2020, 09:08 +0100 schrieb Danny Milosavljevic:
> Hi,
> 
> I've checked guile-gi test/insanity.scm again to find "hard"
> evidence.
> 
> For that, I've just checked out guile-gi anew, then ran
> test/insanity.scm.
> 
> Steps:
> [...]
> That's it.  It fails.
Okay, but it already states something along similar lines in the
description of the issue.
"It is pretty clear to me, that the main culprit here is a different
version of GLib being linked to Guile-GI than the one that should be
loaded through Guile-GI."

> (8) Using attached dlopen logger (gcc -fPIC -shared -o block-open.so
> block-open.c, then edit tools/uninstalled-env bottom before the exec
> to export LD_PRELOAD=$PWD/block-open.so), I get:
> dlopen libguile-gi
> dlopen /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen libguile-gi
> dlopen /gnu/store/xa1vfhfc42x655hi7vxqmbyvwldnz7r0-glib-
> 2.62.6/lib/libgobject-2.0.so.0
> 
> There it is again.
This is not meaningful at all.  Nothing here is "there again" except
for the libguile-gi, which if I understand it correctly is set up
multiple times with different init calls.  In particular, the internal
loading of libgobject by libguile-gi is obscured, hence why you need
(9) to figure out, what actually goes on.

> (9) ldd /home/dannym/src/guile-gi/guile-gi/./.libs/libguile-gi.so.5
> |grep gobject
> [...]
>         libgobject-2.0.so.0 =>
> /gnu/store/4jl613j0d5y6icbxxmwij75fd0i7qpwn-profile/lib/libgobject-
> 2.0.so.0 (0x00007fe2a0677000)
> 
> And there is the other one.
It is not yet clear, that this is "the other one".  You would first
need to readlink it, but indeed, as is pointed out in Guile-GI#96, they
are different.  

But we already know all this from our earlier discussion.  #96 clearly
states, that those two don't line up in `guix environment`, while they
do line up in `guix environment --no-graphs` and `guix build`.  This is
certainly "evidence" and it might even be "hard" depending on how you
view it, but the questions is how to interpret it.

> Now how do I get more info, using Guix tools?
What kind of information do you even want to gather?  To be honest, you
lose me every time you end up establishing knowledge, that already
exists between this thread and the mentioned Guile-GI issue.
I suppose if you want to look at how environments are built, building
them with higher verbosity would be a start, no?
For the purpose of this, it would probably suffice to look at something
simpler than guile-gi in its totality, perhaps just gobject-
introspection + glib (note, that you'd need Scheme code to access the
latter).

Regards, Leo



  reply	other threads:[~2020-11-04  9:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 13:51 GNOME in Guix Leo Prikler
2020-11-03  9:14 ` Danny Milosavljevic
2020-11-03 13:41   ` Leo Prikler
2020-11-03 19:26     ` Danny Milosavljevic
2020-11-03 23:20       ` Leo Prikler
2020-11-04  8:08         ` Danny Milosavljevic
2020-11-04  9:45           ` Leo Prikler [this message]
2020-11-04 13:43             ` Danny Milosavljevic
2020-11-04 14:02               ` Leo Prikler
2020-11-06  9:55   ` Pierre Neidhardt
  -- strict thread matches above, loose matches on Subject: below --
2020-10-29 16:25 Guix Front End (GUI) and making it more mainstream, popular in scientific community Aniket Patil
2020-10-29 19:34 ` Danny Milosavljevic
2020-11-02  7:44   ` Pierre Neidhardt
2020-11-02 10:17     ` GNOME in Guix Danny Milosavljevic
2020-11-06  9:41       ` Pierre Neidhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ea08f910493be04f088db1ac6b98b1ecbd6d968.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).