Replying to [ticket:2047 lbartoletti]:
{{{
/usr/include/stdarg.h:72:2: error: #error this file needs to be ported to
your
compiler
}}}
and
{{{
Error: /usr/include/stdio.h:67: Syntax error at 'va_list'
}}}
So something producing errors in the ISO C headers. The log file doesn't
make any mention of which directory is compiled when the errors occur, but
it looks like lib/python/ctypes, in which case the problem is with the
flags that ctypesgen is passing to the preprocessor.
This needs to be debugged by someone with access to the target system.
Replying to [comment:1 glynn]:
> Replying to [ticket:2047 lbartoletti]:
Testing on FreeBSD 9.0.1 with gcc (GCC) 4.2.1 20070813 patched [FreeBSD]
>
> So something producing errors in the ISO C headers. The log file doesn't
make any mention of which directory is compiled when the errors occur, but
it looks like lib/python/ctypes, in which case the problem is with the
flags that ctypesgen is passing to the preprocessor.
>
{{{
/usr/include/stdarg.h:72:2: error: #error this file needs to be ported to
your
compiler
}}}
/usr/include/stdarg.h is protected by !__GNUCLIKE_BUILTIN_STDARG. Adding
{{{
CFLAGS="-D__GNUCLIKE_BUILTIN_STDARG"
}}}
to the call to configure and hacking lib/python/ctypes/Makefile#L57 by
adding $(CFLAGS) removes this error message. I was not able to spot a
relevant difference between compiling lib/gis (which succeeds) and
lib/python/ctypes, apart from gcc vs. gcc -E. I was also not able to find
any documentation on !__GNUCLIKE_BUILTIN_STDARG?
>
> and
>
{{{
Error: /usr/include/stdio.h:67: Syntax error at 'va_list'
}}}
>
I get ctypes Syntax errors also on GNU/Linux, they appear to be harmless.
It seems that these syntax errors are either indeed harmless and there is
a bug in the ctypes C code parser, or these syntax errors are real,
violating some yet unknown standard.
>
> This needs to be debugged by someone with access to the target system.
I will test on FreeBSD 9.1 next week.
BTW, the standard FreeBSD C compiler clang bombs out for me in lib/gis
with
{{{
fatal error: error in backend: ran out of registers during register
allocation
}}}
unless I set CFLAGS="-D__GNUCLIKE_BUILTIN_STDARG".
I can test on different FreeBSD versions, but I am not familiar with the
intricacies of compiling GNU software on FreeBSD, thus I would appreciate
very much some hints in order to get GRASS working on FreeBSD, ideally
*BSD. BTW, GRASS 7 with standard functionality (modules + GUI without GUI
components requiring ctypes) is working fine for me on FreeBSD 9.1.
Replying to [comment:4 neteler]:
> Could you try with a recent SVN snapshot?
>
> http://grass.osgeo.org/grass64/source/snapshot/
>
> (I am not sure if this report is actually a blocker for 6.4.4)
No answer, downgrading to critical since only Amd64 might be affected.