[MacPorts] #65161: nano @6.3: error: 'const struct stat' has no member named 'st_atimespec' (was: nano @6.3 : Build failure on Mac OS X Tiger)

MacPorts noreply at macports.org
Thu May 12 01:46:54 UTC 2022


#65161: nano @6.3: error: 'const struct stat' has no member named 'st_atimespec'
---------------------------+------------------------
  Reporter:  SerpentChris  |      Owner:  grimreaper
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.2
Resolution:                |   Keywords:  tiger
      Port:  nano          |
---------------------------+------------------------
Changes (by ryandesign):

 * owner:  (none) => grimreaper
 * keywords:   => tiger
 * status:  new => assigned
 * cc: grimreaper@… (removed)
 * cc: jmroot (added)


Comment:

 {{{
 In file included from fstatat.c:48:
 stat-time.h: In function 'get_stat_atime_ns':
 stat-time.h:69: error: 'const struct stat' has no member named
 'st_atimespec'
 stat-time.h: In function 'get_stat_ctime_ns':
 stat-time.h:82: error: 'const struct stat' has no member named
 'st_ctimespec'
 stat-time.h: In function 'get_stat_mtime_ns':
 stat-time.h:95: error: 'const struct stat' has no member named
 'st_mtimespec'
 stat-time.h: In function 'get_stat_atime':
 stat-time.h:121: error: 'const struct stat' has no member named
 'st_atimespec'
 stat-time.h: In function 'get_stat_ctime':
 stat-time.h:135: error: 'const struct stat' has no member named
 'st_ctimespec'
 stat-time.h: In function 'get_stat_mtime':
 stat-time.h:149: error: 'const struct stat' has no member named
 'st_mtimespec'
 }}}

 Yes, I can confirm that on Tiger on Intel.

 `st_atimespec`, `st_ctimespec`, `st_mtimespec` are the normal names for
 those `stat` members on macOS, and nano's configure script detects that.
 (GNU operating systems use different names for them.)

 Looking in /usr/include/sys/stat.h, the `stat` struct will have those
 members ''unless'' `_POSIX_C_SOURCE` is defined.

 I don't see anything in the nano build that sets `_POSIX_C_SOURCE`,
 however I do see `-D_APPLE_C_SOURCE -D_XOPEN_SOURCE=600` being used, and
 in /usr/include/sys/cdefs.h I see that if `_XOPEN_SOURCE` is defined and
 great than or equal to 500, then `_POSIX_C_SOURCE` will be defined.

 So the problem seems to be that when nano's configure script checked to
 see what members were in the the `stat` structure, it didn't use
 `-D_XOPEN_SOURCE=600` so it saw that `st_atimespec` et al were available,
 but then when it tried to compile the actual program it did use
 `-D_XOPEN_SOURCE=600` which made `st_atimespec` et al unavailable. nano
 needs to use the same flags at configure time as it does at build time.

 From config.log, it looks like `-D_XOPEN_SOURCE=600` is coming from
 ncurses:
 {{{
 $ pkg-config ncurses --cflags
 -D_APPLE_C_SOURCE -D_XOPEN_SOURCE=600 -I/opt/local/include
 }}}
 nano may be totally unaware that a dependency like ncurses could
 potentially add such a flag. It may be a bug for ncurses to be doing that.
 What do you think, Josh?

-- 
Ticket URL: <https://trac.macports.org/ticket/65161#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list