[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