#47 no member named 'st_atim' or 'st_mtim' in 'struct stat'

[Ryan Carsten Schmidt]

Hello, I'm the maintainer for optipng in the MacPorts package management system but I'm having trouble building v0.7.5:

osys.c:525:25: error: no member named 'st_atim' in 'struct stat'
        times[0] = sbuf.st_atim;
                   ~~~~ ^
osys.c:526:25: error: no member named 'st_mtim' in 'struct stat'
        times[1] = sbuf.st_mtim;
                   ~~~~ ^
osys.c:527:13: warning: implicit declaration of function 'utimensat' is invalid in C99 [-Wimplicit-function-declaration]
        if (utimensat(AT_FDCWD, dest_path, times, 0) != 0)
            ^
1 warning and 2 errors generated.

On this system:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10
BuildVersion:   14A379b

With this compiler:

$ clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

From this developer tools version:

$ xcodebuild -version
Xcode 6.1
Build version 6A1042b

[Cosmin Truta]

Thank you very much, Ryan, for your report, and also for maintaining the MacPorts package for OptiPNG. I confirm that the problem that you are reporting is a valid build defect, caused by Darwin's lack of full POSIX compliance in handling high-resolution file timestamps.

As a workaround until the fix comes out, you may consider the following patch to src/optipng/osys.c that I derived from the work of Gentoo developers:

-#ifdef AT_FDCWD
+#if defined(AT_FDCWD) && !defined(__APPLE__) && !defined(__SVR4) && !defined(__sun)

Credits: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-gfx/optipng/optipng-0.7.5.ebuild?view=markup

Caution: not tested on Mac OS X 10.10.

[Ryan Carsten Schmidt]

Thanks, I can try that. but I should have pointed out: optipng 0.7.5 builds fine on OS X 10.9 and earlier; this problem is new for OS X 10.10.

[Ryan Carsten Schmidt]

This patch does work, thanks.

The explanation for the problem seems to be that as of 10.10, AT_FDCWD is defined in the system headers (depending on certain conditions), whereas it didn't used to be.

[Cosmin Truta]

Thank you, Ryan, for the confirmation.

Your observation about AT_FDCWD is correct. The POSIX feature detection code in the osys module is overly optimistic: it assumes that, if AT_FDCWD exists, then all functions that use it (including utimensat) also exist; and that, apparently, is not the case on OS X.

Moreover, there seems to be an unrelated POSIX compliance issue here: the stat structure members st_atim and st_mtim are missing. I noticed that OS X does have st_atimespec and st_mtimespec (the same thing, just with a different name), perhaps from its BSD heritage. Interestingly, though, FreeBSD does have st_atim and st_mtim nowadays.

For what is worth, OS X is registered as SUSv3 (i.e. POSIX:2001) compliant. The features I'm mentioning here are from SUSv4 (i.e. POSIX:2008).

Back to the problem of high-res time stamps: in order to support them on OS X, Solaris, NetBSD, as well as any other systems that lack this particular POSIX:2008 feature, the proper solution shall consist in an alternate BSD-specific implementation path that uses st_mtimespec and friends, and sets the time stamp using utimes (an older, legacy function, which accepts microseconds) instead of utimensat (which accepts nanoseconds).

Here are the relevant POSIX documents:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/utimensat.html

[Dmitry Egorov]

Doesn't compile on FreeBSD.

FreeBSD user@xxx 10.1-STABLE-r273058 FreeBSD 10.1-STABLE-r273058 #0 r273058M: Tue Oct 14 08:12:54 UTC 2014 user@yyy:/usr/obj/usr/src/sys/RCTL amd64

[Cosmin Truta]

Thank you for letting me know. I'm sorry I don't have a FreeBSD installation to test it right now. Could you please tell me what exactly is failing?

Does it fail with, or without the above-mentioned AT_FDCWD workaround? Does it make a difference if you add __FreeBSD__ to that workaround?

[Trung Le]

@Cosmin Truta: I can verify that the workaround works perfectly on OSX 10.10.

Any chance that we could get this out soon?

[Trung Le]

@Cosmin: I could help with the fail build on FreeBSD

I verify that it fails for both with and without the AT_FDCWD workaround

I also tried to add in !defined(__FreeBSD__) and it passes

Can we have a patch soon?

[Computer Guru]

Just curious if there's a reason this patch wasn't upstreamed? It's the only issue blocking compliation on OS X out-of-the-box.

[Ramona Truta]

Fixed in version 0.7.6.