‘stat_t’ {aka ‘struct stat’} has no member named ‘st_mtim’;

[lancethepants]

Coming on this issue when compiling v1.4.4. Did not experience this issue in v1.4.3.

util.c: In function ‘UTIL_setFileStat’:
util.c:76:31: error: ‘stat_t’ {aka ‘struct stat’} has no member named ‘st_mtim’; did you mean ‘st_mtime’?
76 | timebuf[1] = statbuf->st_mtim;
| ^~~~~~~
| st_mtime
: recipe for target 'util.o' failed

arm architecture
kernel 2.6.36.4
uclibc-ng 1.0.32

[felixhandte]

Fascinating! POSIX 2008 demands that these fields are present (source). This code is guarded by a macro guard that more or less checks that _POSIX_VERSION >= 200809L. Can you share the value of the macro _POSIX_VERSION when you compile zstd in this environment?

[lancethepants]

In util.c, I threw in

#include <boost/preprocessor/stringize.hpp>
#pragma message "PLATFORM_POSIX_VERSION=" BOOST_PP_STRINGIZE(PLATFORM_POSIX_VERSION)

and it gives me 200809L
util.c:66:9: note: #pragma message: PLATFORM_POSIX_VERSION=200809L

[lancethepants]

#include <boost/preprocessor/stringize.hpp>
#pragma message "_POSIX_VERSION=" BOOST_PP_STRINGIZE(_POSIX_VERSION)
util.c:67:9: note: #pragma message: _POSIX_VERSION=200809L

[felixhandte]

Ok, that suggests that either something about your build environment is incorrectly defining _POSIX_VERSION or your platform is lying about being POSIX compliant. Can you share how you're building zstd? Just make?

[lancethepants]

Yes, tried make and cmake

So I tried throwing in -D_POSIX_C_SOURCE in the cflags, and then it compiles fine. Also-D_BSD_SOURCE on it's own allowed it to compile as well.

[felixhandte]

So @lancethepants, I'm not really sure how best to resolve this issue. It sounds like your environment is straight up lying about complying with POSIX 2008. I'm not opposed to including a workaround that detects this quirk, but I'm not sure what that would be.

Is it sufficient for your purposes to just perform the workaround you found manually? Do you want us to include a fix for this?

[lancethepants]

I'll just do my manual workaround.
thanks!

[borice]

Sorry to re-open this, @lancethepants where did you add the -D_POSIX_C_SOURCE to make it compile? I am encountering the same error and don't see any CFLAGS definition in the generated Makefile.... but I might not be looking in the right place.

Thanks.

[lancethepants]

@borice
Just passing CFLAGS to make.

CFLAGS=-D_POSIX_C_SOURCE \
make

[felixhandte]

@borice, we had another report of this issue in #1897, which resulted in reverting the change that introduced this. So you could build off of the dev branch now and you would avoid this issue.

(Going forward, we're working to bring back the use of st_mtim safely in #1920, so you could also try applying that fix.)

[borice]

The changes in #1920 worked for me - thank you!

[ewildgoose]

Hi, I have the original problem when using uclibc-ng on both x86 and amd64. I still see the issue using zstd-1.4.5.

My investigation into this leads me to think the root cause (at least for uclibc-ng) is a difference in define used to enable the st_mtim macros in <bits/stat.h>. In glibc it's enough to:

#define _POSIX_C_SOURCE 200809L

Which in turn defines __USE_XOPEN2K8

However, in uclibc-ng (and this may be a bug/misfeature), we need to define __USE_MISC (or _BSD_SOURCE, which triggers __USE_MISC to be defined as a side effect).

The following patch to zstd should resolve compilation under uclibc-ng. I can't see that it will cause issues with other platforms - seems safe?

Could you please consider accepting upstream:

--- a/programs/platform.h	2020-07-06 14:44:59.835767828 +0000
+++ b/programs/platform.h	2020-07-06 14:41:35.728320951 +0000
@@ -102,6 +102,12 @@
 #      define PLATFORM_POSIX_VERSION 1
 #    endif

+#    ifdef __UCLIBC__
+#     ifndef __USE_MISC
+#      define __USE_MISC
+#     endif
+#    endif
+
 #  else  /* non-unix target platform (like Windows) */
 #    define PLATFORM_POSIX_VERSION 0
 #  endif

[Cyan4973]

Sure @ewildgoose , the proposed patch looks safe enough.