GNOME Bugzilla – Bug 631507
g-ir-scanner can't handle some of Mac OS X's system headers
Last modified: 2015-02-07 17:01:55 UTC
Build process of libgda 4.0.11 calls g-ir-scanner tool, which scans gda's sources and follows chain of includes to system headers. Here's the error I get: /usr/include/libkern/i386/_OSByteOrder.h:49: syntax error, unexpected '{', expecting ',' or ';' in '{' at '{' /usr/include/libkern/i386/_OSByteOrder.h:58: syntax error, unexpected '{', expecting ',' or ';' in '{' at '{' /usr/include/libkern/i386/_OSByteOrder.h:96: syntax error, unexpected '{', expecting ',' or ';' in '{' at '{' /usr/include/stdlib.h:272: syntax error, unexpected '^' in 'int atexit_b(void (^)(void));' at '^' /usr/include/stdlib.h:274: syntax error, unexpected '^' in ' size_t, int (^)(const void *, const void *));' at '^' /usr/include/stdlib.h:274: syntax error, unexpected ',', expecting identifier or '(' in ' size_t, int (^)(const void *, const void *));' at ',' /usr/include/stdlib.h:274: syntax error, unexpected ')', expecting identifier or '(' in ' size_t, int (^)(const void *, const void *));' at ')' /usr/include/stdlib.h:301: syntax error, unexpected '^' in ' int (^)(const void *, const void *));' at '^' /usr/include/stdlib.h:301: syntax error, unexpected ',', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ',' /usr/include/stdlib.h:301: syntax error, unexpected ')', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ')' /usr/include/stdlib.h:307: syntax error, unexpected '^' in ' int (^)(const void *, const void *));' at '^' /usr/include/stdlib.h:307: syntax error, unexpected ',', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ',' /usr/include/stdlib.h:307: syntax error, unexpected ')', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ')' /usr/include/stdlib.h:313: syntax error, unexpected '^' in ' int (^)(const void *, const void *));' at '^' /usr/include/stdlib.h:313: syntax error, unexpected ',', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ',' /usr/include/stdlib.h:313: syntax error, unexpected ')', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ')' /usr/include/stdlib.h:319: syntax error, unexpected '^' in ' int (^)(const void *, const void *));' at '^' /usr/include/stdlib.h:319: syntax error, unexpected ',', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ',' /usr/include/stdlib.h:319: syntax error, unexpected ')', expecting identifier or '(' in ' int (^)(const void *, const void *));' at ')' I'm supplying these 2 headers in attachments
Created attachment 171815 [details] Failing header
Created attachment 171816 [details] Second failing header
^ is a block/closure syntax feature, maybe only on apple's compilers right now? See http://www.macresearch.org/cocoa-scientists-part-xxvii-getting-closure-objective-c for some info about it.
same with gobject-introspecion 0.10.2 and libgda 4.2.4
Is it really just one issue? I cannot see any closure around _OSByteOrder.h:49 Would be helpful to identify further the individual issues that make compilation on OSX fail and file separate bugs with that information. About the former, may be some issue with the whitespace formatting in that header. A fix is likely to be needed in: http://git.gnome.org/browse/gobject-introspection/tree/giscanner/scannerparser.y About the latter, we could extend the parser to understand ^, or just make sure that __BLOCKS__ is undefined when building on OSX.
Regarding the _OSByteOrder.h errors, the macro expansion of the declarations concerned look like static __inline__ __uint16_t _OSSwapInt16( __uint16_t _data ) { ... } It seems like the scanner doesn't know about __inline__. I tried to hack the lexer to recognise "__inline__" as a synonym for "inline", but it didn't seem to help. So either I performed the hacking incorrectly, or there is more than one problem here, or I've misdiagnosed the problem entirely.
Adding __inline__ to the lexer fixes the problem for me.
could you tell me how to add __inline__ to the lexer? thanks (In reply to comment #7) > Adding __inline__ to the lexer fixes the problem for me.
Created attachment 253110 [details] [review] scanner: Report __inline__ as the inline token Improves support on MacOS when scanning system headers.
Review of attachment 253110 [details] [review]: Looks fine to me, thanks for the patch!
Attachment 253110 [details] pushed as b58425b - scanner: Report __inline__ as the inline token
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]