Introspection build issue
matthiasclasen opened this issue · comments
We're seeing this on i686 in the RHEL buildsystem:
<mock-chroot> sh-5.0# ninja -C build
ninja: Entering directory `build'
[1/2] Generating Graphene-1.0.gir with a custom command
gcc -pthread -E -D_GNU_SOURCE -DGRAPHENE_COMPILATION -I. -I/builddir/build/BUILD/graphene-1.10.4/build/include -I/builddir/build/BUILD/graphene-1.10.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gobject-introspection-1.0 -I/builddir/build/BUILD/graphene-1.10.4/src -I/builddir/build/BUILD/graphene-1.10.4/build/src -o g-ir-cpp-w81vx1kk.i -C /builddir/build/BUILD/graphene-1.10.4/build/g-ir-cpp-w81vx1kk.c
/usr/lib/gcc/i686-redhat-linux/10/include/stddef.h:424: syntax error, unexpected identifier in ' __float128 __max_align_f128 __attribute__((__aligned__(__alignof(__float128))));' at '__float128'
gcc -pthread -D_GNU_SOURCE -I/builddir/build/BUILD/graphene-1.10.4/src -I/builddir/build/BUILD/graphene-1.10.4/build/src -I/builddir/build/BUILD/graphene-1.10.4/build/include -I/builddir/build/BUILD/graphene-1.10.4/include -I/builddir/build/BUILD/graphene-1.10.4/build/include -I/builddir/build/BUILD/graphene-1.10.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/builddir/build/BUILD/graphene-1.10.4/build/include -I/builddir/build/BUILD/graphene-1.10.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gobject-introspection-1.0 -c /builddir/build/BUILD/graphene-1.10.4/build/tmp-introspectc67xtc2g/Graphene-1.0.c -o /builddir/build/BUILD/graphene-1.10.4/build/tmp-introspectc67xtc2g/Graphene-1.0.o -Wno-deprecated-declarations -pthread
g-ir-scanner: link: gcc -pthread -o /builddir/build/BUILD/graphene-1.10.4/build/tmp-introspectc67xtc2g/Graphene-1.0 /builddir/build/BUILD/graphene-1.10.4/build/tmp-introspectc67xtc2g/Graphene-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/builddir/build/BUILD/graphene-1.10.4/build/src -Wl,-rpath,/builddir/build/BUILD/graphene-1.10.4/build/src -lgraphene-1.0 -lm -lgobject-2.0 -lglib-2.0 -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
[2/2] Generating Graphene-1.0.typelib with a custom command
/usr/lib/gcc/i686-redhat-linux/10/include/stddef.h:424: syntax error, unexpected identifier in ' __float128 __max_align_f128 attribute((aligned(__alignof(__float128))));' at '__float128'
This comes from a system header; I guess g-ir-scanner is choking on some compiler attribute, or maybe at the __float128 type?
Yes, it is choking on __float128. But why only on i686 ?
Ah, stddef.h has:
/* _Float128 is defined as a basic type, so max_align_t must be
sufficiently aligned for it. This code must work in C++, so we
use __float128 here; that is only available on some
architectures, but only on i386 is extra alignment needed for
__float128. */
#ifdef __i386__
__float128 __max_align_f128 __attribute__((__aligned__(__alignof(__float128))));
#endif
The whole thing is inside an
#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \
|| (defined(__cplusplus) && __cplusplus >= 201103L)
#endif /* C11 */
Are we using C11 ?
No, but then again this is g-ir-scanner: it needs to do two passes, one without macro expansion and one with macro expansion.
giscanner/scannerlexer.l has:
"float" { return BASIC_TYPE; }
"_Float16" { return BASIC_TYPE; }
"_Float32" { return BASIC_TYPE; }
"_Float64" { return BASIC_TYPE; }
"_Float128" { return BASIC_TYPE; }
"_Float32x" { return BASIC_TYPE; }
"_Float64x" { return BASIC_TYPE; }
"_Float128x" { return BASIC_TYPE; }
but nothing for __float128
Maybe this would do ?
diff --git a/giscanner/scannerlexer.l b/giscanner/scannerlexer.l
index cfec4d58..8b3ecfe2 100644
--- a/giscanner/scannerlexer.l
+++ b/giscanner/scannerlexer.l
@@ -217,6 +217,8 @@ stringtext ([^\\\"])|(\\.)
"enum" { return ENUM; }
"extern" { return EXTERN; }
"float" { return BASIC_TYPE; }
+"__float80" { return BASIC_TYPE; }
+"__float128" { return BASIC_TYPE; }
"_Float16" { return BASIC_TYPE; }
"_Float32" { return BASIC_TYPE; }
"_Float64" { return BASIC_TYPE; }
Possibly. It would be great if the C library didn't add random types, of course. But at this point, you should open an issue on GitLab. 😉
Going there