I forgot
gobject-introspection-1.42.0-1.el7.x86_64

I can reproduce with these:

glib2-2.44.1-1.fc22.x86_64
gobject-introspection-1.44.0-1.fc22.x86_64
python3-gobject-3.16.1-1.fc22.x86_64
pygobject3-3.16.1-1.fc22.x86_64

Strictly speaking, using the GLib macros in a language binding is not a great plan — also because the introspection scanner does not support complex macros in the first place.

G_DIR_SEPARATOR_S and G_SEARCHPATH_SEPARATOR_S are defined in terms of G_OS_WIN32, with the Windows macros defined first; this is confusing the introspection scanner, since it has to do a pass before macros are expanded, but it will ignore the #ifdef G_OS_WIN32 and add the first symbol and value unconditionally. Once the scanner reaches the second definition, it'll append it to the list of symbols.

In theory, the scanner should allow for constants to appear multiple times, but it's not implemented:

giscanner/transformer.py:_append_new_node()

        # Special case constants here; we allow duplication to sort-of
        # handle #ifdef.  But this introduces an arch-dependency in the .gir
        # file.  So far this has only come up scanning glib - in theory, other
        # modules will just depend on that.
        if isinstance(original, ast.Constant) and isinstance(node, ast.Constant):
            pass

It's worth noting that the code has been the same since 2010, and that the GIR already contains arch-dependent bits. The missing implementation means that any constant that already exists in the AST gets dropped on the floor, which is what causes the Windows-specific values to appear in the GIR and, thus, in the typelib.

There are two plausible solutions for this problem:

 1. Since we don't support cross-compilation, we could check the current platform and push platform specific data into the AST by way of the GLib conditionals; this means that we standardise on G_OS_WIN32 for Windows and G_OS_UNIX for any Unix-like system. These are public API of GLib, so it wouldn't be terrible.

 2. If we want to at least try and not make the cross-compilation situation worse, we need to add conditionals to the XML, e.g.

  <if-condition-set key="platform" value="win32">
    <constant name="DIR_SEPARATOR_S" value="\">
      <doc>…</doc>
      <type name="utf8" c:type="gchar*"/>
    </constant>
  </if-condition-set>
  <if-condition-set key="platform" value="unix">
    <constant name="DIR_SEPARATOR_S" value="/">
      <doc>…</doc>
      <type name="utf8" c:type="gchar*"/>
    </constant>
  </if-condition-set>

The g-ir-compiler would then use the existing platform to decide which value to compile into the typelib file.

Filed also as https://bugzilla.redhat.com/show_bug.cgi?id=1223490

It would be great if there was simply an annotation to mark platform-specific constants (and maybe types, but constants is where the most pain is), so that the binding generators are aware that the definitions vary per platform and manual overrides are needed.

(In reply to Mikhail Zabaluev from comment #7)
> It would be great if there was simply an annotation to mark
> platform-specific constants (and maybe types, but constants is where the
> most pain is), so that the binding generators are aware that the definitions
> vary per platform and manual overrides are needed.

Filed away as bug #757165.

Another possible approach is to add a g-ir-scanner option for listing platform-specific source files, so that any symbols defined in those files would be flagged as platform-specific. This requires that on the source side, all platform-specific definitions are confined to dedicated header or source files. Unfortunately, this is not completely so even in glib; see bug #757284 and bug #757294.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/132.