Re: __uint128_t support in gobject introspection

[Mark Salter <msalter redhat com>]

On Thu, 2013-05-02 at 10:41 -0400, Colin Walters wrote:
> Hi Mark,
>
> On Mon, 2013-04-29 at 12:43 -0400, Mark Salter wrote:
> > I ran into an issue in gobject-introspection while bootstrapping fedora
> > packages for AArch64. I was able to build gobject-introspection but when
> > some other packages run the scanner, 
>
> What components are causing the scanner to ultimately include kernel
> headers?  I'm guessing this is systemd.  If possible, it's nice to avoid
> doing so.  I'll be the first to say that the scanner is really not the
> world's best C parser, it works best when it's fed only pure GObject.

I'm not sure what you mena by component here. I see it in build logs for
at-spi2-core, gdb-pixbuf, gtk2, pango, and libgusb. Those may be the
only packages we've built so far which use the scanner.

--Mark

> > I see:
> >
> >   /usr/include/asm/sigcontext.h:53: syntax error, unexpected identifier in ' __uint128_t vregs[32];' at 
> > '__uint128_t'
> >   /usr/include/asm/ptrace.h:75: syntax error, unexpected identifier in ' __uint128_t vregs[32];' at 
> > '__uint128_t'
> >   /usr/include/asm/sigcontext.h:53: syntax error, unexpected identifier in ' __uint128_t vregs[32];' at 
> > '__uint128_t'
> >
> > So, aarch64 gcc has a builtin __uint128_t which the kernel exposes in
> > some of its headers. It seems like gobject-introspection about this
> > type. Am I missing anything? It sees like an easy enough thing to do
> > from a quick glance at the code, but I could just be naive about it.
>
> We could probably ignore the type easily enough.  But allowing its use
> in introspectable API would be a lot harder because bindings would have
> to be updated.

I think ignoring it would probably be fine. We're just building existing
code. No new APIs.

--Mark