Opened 11 years ago

Closed 11 years ago

#39629 closed defect (wontfix)

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

Reported by: jeremyhu (Jeremy Huddleston Sequoia) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: cooljeanius (Eric Gallager), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), neverpanic (Clemens Lang)
Port: gobject-introspection

Description

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

Attachments (4)

x86_64-JSCore-1.0.typelib (268 bytes) - added by jeremyhu (Jeremy Huddleston Sequoia) 11 years ago.
x86_64 JSCore-1.0.typelib
i386-JSCore-1.0.typelib (268 bytes) - added by jeremyhu (Jeremy Huddleston Sequoia) 11 years ago.
i386 JSCore-1.0.typelib
muniversal-1.0.tcl (38.5 KB) - added by neverpanic (Clemens Lang) 11 years ago.
Patch against the muniversal PortGroup executing g-ir-generate and comparing the output
muniversal.diff (3.2 KB) - added by neverpanic (Clemens Lang) 11 years ago.
Patch against the muniversal PortGroup executing g-ir-generate and comparing the output

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: x86_64-JSCore-1.0.typelib added

x86_64 JSCore-1.0.typelib

Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: i386-JSCore-1.0.typelib added

i386 JSCore-1.0.typelib

comment:1 Changed 11 years ago by 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>

comment:2 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:3 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:4 Changed 11 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

comment:5 Changed 11 years ago by neverpanic (Clemens Lang)

Cc: cal@… added

I've attached a patch.

Changed 11 years ago by neverpanic (Clemens Lang)

Attachment: muniversal-1.0.tcl added

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

Changed 11 years ago by neverpanic (Clemens Lang)

Attachment: muniversal.diff added

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

comment:6 Changed 11 years ago by 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.)

comment:7 Changed 11 years ago by 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...

comment:8 Changed 11 years ago by neverpanic (Clemens Lang)

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.