Hi,

On Mon, 02 Nov 2020 08:44:29 +0100
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Danny Milosavljevic <dannym@scratchpost.org> 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  
> 
> 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 <stdio.h>
#include <dlfcn.h>

// https://stackoverflow.com/questions/43582165/handling-global-variables-in-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