Description
I'm having an issue (when I wasn't before) compiling the latest v3.0.78 in Cygwin. Here is the issue when I run make:
$ make
make all-recursive
make[1]: Entering directory '/home/Nate/moosefs-3.0.78'
Making all in mfstests
make[2]: Entering directory '/home/Nate/moosefs-3.0.78/mfstests'
CC mfstest_datapack-mfstest_datapack.o
CCLD mfstest_datapack.exe
CC mfstest_clocks-mfstest_clocks.o
In file included from /usr/include/time.h:12:0,
from /usr/include/sys/time.h:268,
from mfstest_clocks.c:22:
/usr/include/sys/reent.h:276:3: error: expected specifier-qualifier-list before ‘_fpos64_t’
_fpos64_t _EXFNPTR(_seek64, (struct _reent *, _PTR, _fpos64_t, int));
^
In file included from mfstest_clocks.c:25:0:
/usr/include/stdio.h:58:9: error: unknown type name ‘_fpos64_t’
typedef _fpos64_t fpos_t;
^
make[2]: *** [Makefile:737: mfstest_clocks-mfstest_clocks.o] Error 1
make[2]: Leaving directory '/home/Nate/moosefs-3.0.78/mfstests'
make[1]: *** [Makefile:462: all-recursive] Error 1
make[1]: Leaving directory '/home/Nate/moosefs-3.0.78'
make: *** [Makefile:394: all] Error 2
It seems all related to not knowing about the "_fpos64_t" type and google isn't that helpful.
The funny thing is this... I have the code base from an older version of Moose (3.0.73) still in my Cygwin database from a few months ago. Since that time I had reinstalled my OS (my Cygwin dir structure was located on a different partition and remained in place). So I reran make on the older one just to see what would happen. And sure enough I got the same error (even though I compiled perfectly just a month ago from the very same files!).
So I'm pretty sure it's NOT something in the MooseFS code but likely Cygwin. Still I'm trying lots of things here (even installed MinGW and tried compiling with that but no go). I'm hoping you guys can help me.
All I really need is the chunkserver for 1 windows box... I don't use Windows for anything else... all my other boxes are Linux.
In the meantime I will continue to use this 3.0.74 version I comiled last month... but going into the future this won't be optimal.