Re: __uint128_t support in gobject introspection
On Mon, 2013-05-06 at 16:02 -0400, Mark Salter wrote: That got rid of the error messages I was seeing. Found a reviewer; merged to master. Feel free to backport to the Fedora packages if you want. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
On Tue, 2013-05-07 at 09:14 -0400, Colin Walters wrote: On Mon, 2013-05-06 at 16:02 -0400, Mark Salter wrote: That got rid of the error messages I was seeing. Found a reviewer; merged to master. Feel free to backport to the Fedora packages if you want. I do want. :-) Will file a bz with patch there. Thanks for the help. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
On Sun, 2013-05-05 at 14:56 -0400, Colin Walters wrote: On Thu, 2013-05-02 at 14:00 -0400, Mark Salter wrote: I think ignoring it would probably be fine. We're just building existing code. No new APIs. Can you try https://bugzilla.gnome.org/show_bug.cgi?id=699722 and let me know if it works? That got rid of the error messages I was seeing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
On Thu, 2013-05-02 at 14:00 -0400, Mark Salter wrote: I think ignoring it would probably be fine. We're just building existing code. No new APIs. Can you try https://bugzilla.gnome.org/show_bug.cgi?id=699722 and let me know if it works? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
On Sun, 2013-05-05 at 14:56 -0400, Colin Walters wrote: On Thu, 2013-05-02 at 14:00 -0400, Mark Salter wrote: I think ignoring it would probably be fine. We're just building existing code. No new APIs. Can you try https://bugzilla.gnome.org/show_bug.cgi?id=699722 and let me know if it works? Yes, I will. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
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 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: __uint128_t support in gobject introspection
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
