Need help with parsing stdio.h

Dear All,

I've just started to work with GlueGen, with the goal of using from Java the C software running at an observatory.

I successfully built GlueGen 2.1.4 from scratch on Scientific Linux 5.5, from the downloaded "gluegen-v2.1.4.tar.7z" archive.
When I try to generate JNI code from any header file that includes "stdio.h", or using that include file directly, I get the following error:

gluegen-v2.1.4/build 1397 > java -jar gluegen.jar -I/usr/include -CmyGlueGen.cfg /usr/include/stdio.h
Exception in thread "main" java.lang.RuntimeException: Exception occurred while generating glue code.
        at com.jogamp.gluegen.GlueGen.run(GlueGen.java:307)
        at com.jogamp.gluegen.GlueGen.main(GlueGen.java:366)
Caused by: java.io.IOException: Expected token '40' but got '__need_FILE' at file /usr/include/stdio.h, line 23
        at com.jogamp.gluegen.pcpp.PCPP.nextRequiredToken(PCPP.java:279)
        at com.jogamp.gluegen.pcpp.PCPP.handleIfRecursive(PCPP.java:935)
        at com.jogamp.gluegen.pcpp.PCPP.handleIfRecursive(PCPP.java:886)
        at com.jogamp.gluegen.pcpp.PCPP.handleIf(PCPP.java:831)
        at com.jogamp.gluegen.pcpp.PCPP.preprocessorDirective(PCPP.java:410)
        at com.jogamp.gluegen.pcpp.PCPP.parse(PCPP.java:338)
        at com.jogamp.gluegen.pcpp.PCPP.run(PCPP.java:111)
        at com.jogamp.gluegen.GlueGen.run(GlueGen.java:115)

The manual mentions that "PCPP contains only limited support for #if clauses. Generally speaking, its handling of #if defined(foo) || defined(bar) constructs is limited to approximately what is required to handle the OpenGL header files."

This could be such a case, since stdio.h line 23 has
#if !defined __FILE_defined && defined __need_FILE

On the other hand I cannot believe that I'm the first user of GlueGen who needs to parse stdio.h...
It seems that at http://jogamp.org/log/irc/jogamp_20130808100906.html user doby discussed the same issue, but I don't see a conclusion there.
I suspect that in my case the problem is not with command line vs. ant and antlr.jar on the classpath, since the error occurs while already parsing the header file.

Can anyone tell me what I'm doing wrong here, or point me to a working example that uses stdio.h?

Probably the first thing to do would be to make a very small test case that demonstrates this failure. If you can make a "fail.h" with only the minimum number of lines in it, that's much easier for us to debug than all of stdio.h :)

Also, if you could show that fail.h parses correctly by changing some small thing to create "pass.h", that would narrow the problem down substantially.

Conversely, you might hack a side copy of stdio.h until it passes through gluegen (by manually precomputing the preprocessor directives that fail). Then you'd have a complete list of any other problems that gluegen might have with the file. This would tell you how far away gluegen is from being able to compile the file -- if it need tons of improvements, that's a lot more daunting than just one or two simple fixes.

You need to read the section in the gluegen manual about the need to stub headers that include stdio.h

http://jogamp.org/gluegen/doc/manual/#SecStub

"As much as is possible, GlueGen is intended to operate on unmodified C header files, so that it is easy to upgrade the given C API being bound to Java simply by dropping in a new set of header files. However, most C headers contain references to standard headers like stdio.h, and if this header is parsed by GlueGen, the tool will automatically attempt to generate Java entry points for such routines as fread and fwrite, among others. It is impractical to exclude these APIs on a case by case basis. Therefore, the suggested technique to avoid polluting the binding with these APIs is to "stub out" the headers. "

All the OpenGL OpenAL and OpenCL headers have removed references to stdio.h in order to allow us to only bind the GL AL and CL API without unintentionally map the whole gnu libc API.

Good point -- I should have asked *why* he was trying to parse stdio.h :)

Thanks for the quick replies! I've played a bit with using stubs of included header files and also with commenting out parts of our own C headers. It turns out that our code is making too much use of features that are not supported by GlueGen (macros, anonymous structs, function pointers).

I really like the clear architecture of GlueGen with the separate code generation step, either configurable or using a custom generator, and also the fact that it works without too much runtime magic.
However, given the numerous issues GlueGen had with parsing our code, we may use JNAerator instead, which seems to digest all of our header files.

JNA is slower than JNI and you can still make some requests for enhancement against GlueGen.