warning: __WORDSIZE not defined
Cosmetics to make the -Wundef warning go away:
In file included from /usr/src/local/gromacs/src/gromacs/fileio/tngio.cpp:42:0:
/usr/src/local/gromacs/src/external/tng_io/include/tng/tng_io.h:327:6: warning: "__WORDSIZE" is not defined [-Wundef] # if __WORDSIZE == 64
This is slightly moot as PRId64 and friends are defined for me in inttypes.h which isn't from the GNU C Library.
To make the warning go away, one could wrap the __WORDSIZE testing code in (untested)
#if !defined(PRId64) || !defined(PRI...
However, that whole block probably won't work anyway because:
My headers do not define __STDC_FORMAT_MACROS, so tng_io.h goes on to test another non-standard macro, __WORDSIZE. The irony seems to be that if __WORDSIZE is defined on your system, you probably are running Linux, and therefore have PRId64 and friends defined already.
It reminds me of autoconf's AC_CHECK_SIZEOF([int *]) - presumably there is some sort of cmake equivalent if you really want to provide a fallback?
Or just #error ifndef PRId64 to verify this isn't a problem for anyone.
#1 Updated by Patrick Welche about 4 years ago
Had a quick look at:
and LONG_BIT / WORD_BIT. e.g., for me:
#define LONG_BIT 64
#define WORD_BIT 32
might be a drop in replacement for __WORDSIZE
#2 Updated by Patrick Welche about 4 years ago
- File 0001-Portability-fix-avoid-testing-for-__WORDSIZE-and-__S.patch 0001-Portability-fix-avoid-testing-for-__WORDSIZE-and-__S.patch added
Note change in logic || -> &&. Check this is what was actually meant...
Trivial portability fix attached.
#3 Updated by Mark Abraham about 4 years ago
We can't do that change because TNG is a project that compiles in C, and the C99 spec requires that such format specifier macros are only defined if requested. Merely changing to use WORD_BIT could work, though.
Most of the market for this code branch should be Windows. (What is your case, Patrick?) If so, then TNG could instead use https://github.com/chemeris/msinttypes and the problem goes away.
#10 Updated by Patrick Welche almost 2 years ago
(I seem to be making mistakes these days so check...)
I just compiled 2018.3 successfully on the same (as in, 2 years of updates) system, and didn't see warnings. Looking back at this bug, I wonder why I hit those warnings, as the system did have /usr/include/inttypes.h. I am guessing that, incorrectly, USE_STD_INTTYPES_H wasn't set, and that after a34f8680173ed297635fbe360a62c972f1bd44dd it was.