$ gcc -I ivmai-JCGO-eadc2b4/include/ -I ivmai-JCGO-eadc2b4/include/boehmgc/ -I ivmai-JCGO-eadc2b4/native/ -I classpath-0.93/native/fdlibm/ out/Main.c
In file included from ivmai-JCGO-eadc2b4/include/jcgortl.c:151:0,
ivmai-JCGO-eadc2b4/include/jcgofp.h:106:25: fatal error: fpu_control.h: No such file or directory
Before, I had no ieeefp.h error, but this I found in gnu classpath (-I classpath-0.93/native/fdlibm/)
$ gcc --version
gcc.exe (GCC) 4.6.1
I used JCGO version 1.14
Actually I saw that it compiled with NOFP, but I don't think that it's a proper fix.
gcc -DJCGO_NOFP -I ivmai-JCGO-eadc2b4/include/ -I ivmai-JCGO-eadc2b4/include/boehmgc/ -I ivmai-JCGO-eadc2b4/native/ out/Main.c libs/x86/mingw/libgc.a
Proper fix is to use -D_FPU_CONTROL_H
It looks like you do not have a true MinGW otherwise you would have MCW_EM defined in float.h.
Your system looks like Cygwin. I suggest to use build commands like  (from Samples files)
Yeah, I might have something old.
Anyway, I was surprised it all worked on multithreaded, socket app, on Windows. It translated dependent library fine (commons cli 1.2).
I wrote an article on it: http://rrusin.blogspot.com/2012/08/how-to-create-native-java-app.html.
Interesting article. Thanks.
About iOS: you are right and I'm aware of some apps in the Apple Store that are written in Java and translated using JCGO
About use of GC based on reference-counting (instead of BDWGC):
Java apps may contain cycles in the data structures (which cannot be handled correctly by reference counting).
More over, reference counting in a multi-threaded (on multi-core CPU) environment has a significant performance penalty on incrementing/decrementing a reference counter as this should be an atomic operation involving CPU core cache flushing (speaking in simple words).
On the other hand, there are algorithms that minimizes (or even eliminates) garbage collection pauses (e.g. BDWGC uses parallel mark algorithm running on all available CPU cores; about pause-less GC algorithms you could read, e.g., in http://www.azulsystems.com/sites/www.azulsystems.com/c4_paper_acm.pdf)
Thank you. I will refer these comments from the article.
Problem with hello world
gcc -IC:\JCGO\include -IC:\JCGO\include\boehmgc -IC:\JCGO\native -DJCGO_FFDATA -o hello jcgo_Out\Main.c C:\JCGO\libs\x86\mingw\libgc.a
In file included from C:\JCGO\include/jcgortl.c:151:0,
C:\JCGO\include/jcgofp.h:95:20: fatal error: ieeefp.h: No such file or directory
Which compiler do you use? (The command that you use is for MinGW.) Anyway you could add -D_IEEEFP_H compiler argument.
I'm, use current version of http://www.mingw.org/
I suppose, you should make fix for current libs or change documentation...
It is a bug of MinGW (actually a bug of GCC that used by MinGW). The problem that C:\MinGW\lib\gcc\mingw32\4.8.1\include\float.h does not contain #include_next <float.h> at the end of file (thus C:\MinGW\mingw32\include\float.h is never included thus _MCW_EM is not defined causing JCGO to try to get necessary definitions in fpu_control.h).
As far as I know, GCC 4.6.3 and 4.7.0 have correct float.h.
There are some discussions raised by MinGW maintainers, e.g. https://gcc.gnu.org/ml/gcc-patches/2010-01/msg01114.html
As a workaround, I suggest to add the following command-line parameter: --include C:\MinGW\mingw32\include\float.h).