Brad Douglas wrote: > > > I just committed a compiler test for 'long long' to configure. > > > > I was working on that, and it caused a conflict. Comparing the two > > versions, I reverted it and used mine instead. The differences are: > > > > 1. The current version uses AC_TRY_COMPILE; the previous version used > > AC_TRY_RUN, which is unnecessary effort and won't work when > > cross-compiling. > > I knew I had a cross-compiling issue, but didn't know AC_TRY_COMPILE can > correct it.
AC_TRY_CPP, AC_TRY_COMPILE and AC_TRY_LINK all work when cross-compiling. > > 2. The current version uses HAVE_LONG_LONG_INT rather than > > HAVE_LONG_LONG, as that is the name used by the AC_TYPE_LONG_LONG_INT > > macro in more recent versions of autoconf. > > I originally used HAVE_LONG_LONG_INT, but figured HAVE_LONG_LONG would > suffice. 'long long' implies int. Doesn't hurt to be verbose, though. If it was a "free" choice, I would have skipped the _INT, but it's less effort if we eventually move to a more recent version of autoconf. > > > It defines HAVE_LONG_LONG macro (in include/config.h) so offending code > > > can be segregated. > > > > > > Affected code: > > > - r.info > > > - r.terraflow > > > - g.region > > > - lib/vector/dglib/type.h > > > > I have fixed g.region. I also fixed the r.info fix: > > > > 1. The format specifier for unsigned int is %u; %d is signed. > > > > 2. "long long" values need %llu/%lld rather than %lu/%ld. > > > > AFAICT, dglib and r.terraflow remain untouched. dglib is awkward > > because the 64-bit values are part of the file format, so you can't > > just use a 32-bit int if long long isn't available. > > > > I'm not sure what the situation is with C++, i.e. whether "long long" > > is part of the standard. If it isn't, we need another check; whether > > the C compiler supports "long long" and whether the C++ compiler > > supports it are separate issues. > > AFAIK, there is no C++ standard for 64-bit integrals. Bad news for > r.terraflow. Comments in the g++ headers suggest that "long long" is a GNU extension. Technically, we should really have another compilation check, but I strongly suspect that if the C and C++ compilers aren't "matched", we'll have bigger problems than just "long long". > Anyone get a response on the non-GPL status of it? Not yet. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev