gobject-introspection 1.36.1 sometimes builds files differently for each arch (webkit-gtk)

[jeremyhu (Jeremy Huddleston Sequoia)]

webkit-gtk fails to build +universal because the introspection files differ between archs. This wasn't an issue in the past but seems to now be with the new gobject-introspection.

Command failed: /usr/bin/diff -dw -D __LP64__ "/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_webkit-gtk/webkit-gtk/work/destroot-i386//opt/local/lib/girepository-1.0/JSCore-1.0.typelib" "/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_webkit-gtk/webkit-gtk/work/destroot-x86_64//opt/local/lib/girepository-1.0/JSCore-1.0.typelib" > "/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_webkit-gtk/webkit-gtk/work/destroot-intel//opt/local/lib/girepository-1.0/JSCore-1.0.typelib"; test $? -le 1
Exit code: 1
Error: org.macports.destroot for port webkit-gtk returned: /opt/local/lib/girepository-1.0/JSCore-1.0.typelib differs in /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_webkit-gtk/webkit-gtk/work/destroot-i386 and /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_webkit-gtk/webkit-gtk/work/destroot-x86_64 and cannot be merged

The difference between the two are in 4 of the last 6 bytes:

-0000400      0000    0000    fc07    7470    0000    3a63                
+0000400      0000    0000    fc07    0000    0000    0000                
 0000414

or

-0000400   \0  \0  \0  \0  \a 374   p   t  \0  \0   c   :                
+0000400   \0  \0  \0  \0  \a 374  \0  \0  \0  \0  \0  \0                
 0000414

[jeremyhu (Jeremy Huddleston Sequoia)]

x86_64 JSCore-1.0.typelib

[jeremyhu (Jeremy Huddleston Sequoia)]

i386 JSCore-1.0.typelib

[jeremyhu (Jeremy Huddleston Sequoia)]

Looks like those bytes are garbage since both represent the same GIR:

$ g-ir-generate work/destroot-i386/opt/local/lib/girepository-1.0/JSCore-1.0.typelib
<?xml version="1.0"?>
<repository version="1.0"
            xmlns="http://www.gtk.org/introspection/core/1.0"
            xmlns:c="http://www.gtk.org/introspection/c/1.0"
            xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
  <namespace name="JSCore" version="1.0" shared-library="webkitgtk-1.0">
    <function name="EvaluateScript" c:identifier="JSEvaluateScript">
      <return-value transfer-ownership="none">
        <type name="none"/>
      </return-value>
    </function>
  </namespace>
</repository>

$ g-ir-generate work/destroot-x86_64/opt/local/lib/girepository-1.0/JSCore-1.0.typelib
<?xml version="1.0"?>
<repository version="1.0"
            xmlns="http://www.gtk.org/introspection/core/1.0"
            xmlns:c="http://www.gtk.org/introspection/c/1.0"
            xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
  <namespace name="JSCore" version="1.0" shared-library="webkitgtk-1.0">
    <function name="EvaluateScript" c:identifier="JSEvaluateScript">
      <return-value transfer-ownership="none">
        <type name="none"/>
      </return-value>
    </function>
  </namespace>
</repository>

[jeremyhu (Jeremy Huddleston Sequoia)]

r107667 but leaving open, we should update that to compare the output of g-ir-generate

[cooljeanius (Eric Gallager)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[neverpanic (Clemens Lang)]

I've attached a patch.

[neverpanic (Clemens Lang)]

Patch against the muniversal PortGroup executing g-ir-generate and comparing the output

[neverpanic (Clemens Lang)]

Patch against the muniversal PortGroup executing g-ir-generate and comparing the output

[neverpanic (Clemens Lang)]

I've updated the patch; please ignore muniversal-1.0.tcl. However, I'm not sure we should really do this. My tests with gtk3 seem to indicate problems that might be hard to avoid:

--- /tmp/muniversal.IgU5XXNk/x86_64-Gtk-3.0	2013-07-21 00:51:53.000000000 +0200
+++ /tmp/muniversal.IgU5XXNk/i386-Gtk-3.0	2013-07-21 00:51:53.000000000 +0200
@@ -40278,6 +40278,11 @@
           <type name="Gdk.RGBA"/>
         </array>
       </field>
+      <field name="padding" writable="1">
+        <array fixed-size="2">
+          <type name="guint32"/>
+        </array>
+      </field>
     </record>
     <record name="TextAttributes" glib:type-name="GtkTextAttributes" glib:get-type="gtk_text_attributes_get_type">
       <field name="refcount">

(Note: The files have more than 62500 lines. This is the only difference.)

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, and chance are that's because something above it has <type name="long" />, so they need to pad the struct on 32bit.

IMO, a better fix would be to fix the struct to be identical on both archs, but this is a common issue. Perhaps we just bite the bullet and say that YMMV if you try to introspect the secondary archs...

[neverpanic (Clemens Lang)]

I don't think committing my patch would be doing any good here, except breaking introspection for secondary archs. Let's just not do that and continue to assume the difference is trivial.