On attempting to build x11-wm/xfce4 on an ibook G4 running 11.1-RELEASE with a ports tree updated on
2017/10/04, I encountered a failure indevel/gobject-introspection:

ERROR: Failed to re-parse gir file; scanned='/tmp/tmpASp2z3.gir' passthrough='/tmp/tmpMHZdPr.gir'
gmake[3]: *** [Makefile:3521: Gio-2.0.gir] Error 1
gmake[3]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0'
gmake[2]: *** [Makefile:2810: all-recursive] Error 1
gmake[2]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0'
gmake[1]: *** [Makefile:1570: all] Error 2
gmake[1]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0'
===> Compilation failed unexpectedly.

Rifling through the source at giscanner/scannermain.py, one finds that the failure stems from a simple comparison of the two named files and that they do in fact differ in one line
(out of ~92,000):

*** tmpASp2z3.gir    Wed Oct 11 23:24:40 2017
--- tmpMHZdPr.gir    Wed Oct 11 23:24:41 2017
***************
*** 45286,45292 ****
          <return-value transfer-ownership="none">
<doc xml:space="preserve">the new #GIOExtensionPoint. This object is
     owned by GIO and should not be freed.</doc>
!           <type name="IOExtensionPoint" c:type="GIOExtensionPoint*"/>
          </return-value>
          <parameters>
            <parameter name="name" transfer-ownership="none">
--- 45286,45292 ----
          <return-value transfer-ownership="none">
<doc xml:space="preserve">the new #GIOExtensionPoint. This object is
     owned by GIO and should not be freed.</doc>
!           <type name="IOExtensionPoint"="GFilesystemPreviewnPoint*"/>
          </return-value>
          <parameters>
            <parameter name="name" transfer-ownership="none">

The line in the "passthrough" file appears to have a 20 byte blob of alien substring from elsewhere in the file dropped into it. Curiously, the final character of that substring is at offset 0x1fffff in the file. I could be wrong, but I'm having a hard time believing that that's just a coincidence.
This is repeatable.

Is this port known to be broken on ppc32? Any advice on how best to track it down? My knowledge of python is thus far inadequate to decipher what the function that generates the passthrough file is doing, so I'll have to work on that. I'm not sure the problem isn't at a lower level though.

Thanks,

-Steve


_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"

Reply via email to