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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
