leo-arch / clifm

The shell-like, command line terminal file manager: simple, fast, extensible, and lightweight as hell.
https://github.com/leo-arch/clifm/wiki
GNU General Public License v2.0
1.29k stars 41 forks source link

Build failure on 10.6: error: 'struct stat' has no member named 'st_birthtimespec'; did you mean 'st_atimespec'? #250

Closed barracuda156 closed 10 months ago

barracuda156 commented 10 months ago

Trying to build on 10.6, I get the following error:

/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_sysutils_clifm/clifm/work/clifm-1.13/src/helpers.h:223:19: error: 'struct stat' has no member named 'st_birthtimespec'; did you mean 'st_atimespec'?
  223 | # define ST_BTIME st_birthtimespec
      |                   ^~~~~~~~~~~~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_sysutils_clifm/clifm/work/clifm-1.13/src/listing.c:2351:68: note: in expansion of macro 'ST_BTIME'
 2351 |                         file_info[n].time = stat_ok ? (time_t)attr.ST_BTIME.tv_sec : 0;
      |                                                                    ^~~~~~~~
make[2]: *** [CMakeFiles/clifm.dir/src/listing.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....

sys/stat.h has the following:

#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
/*
 * XXX So deprecated, it would make your head spin
 *
 * The old stat structure.  In fact, this is not used by the kernel at all,
 * and should not be used by user space, and should be removed from this
 * header file entirely (along with the unused cvtstat() prototype in
 * vnode_internal.h).
 */
struct ostat {
    __uint16_t  st_dev;     /* inode's device */
    ino_t       st_ino;     /* inode's number */
    mode_t      st_mode;    /* inode protection mode */
    nlink_t     st_nlink;   /* number of hard links */
    __uint16_t  st_uid;     /* user ID of the file's owner */
    __uint16_t  st_gid;     /* group ID of the file's group */
    __uint16_t  st_rdev;    /* device type */
    __int32_t   st_size;    /* file size, in bytes */
    struct  timespec st_atimespec;  /* time of last access */
    struct  timespec st_mtimespec;  /* time of last data modification */
    struct  timespec st_ctimespec;  /* time of last file status change */
    __int32_t   st_blksize; /* optimal blocksize for I/O */
    __int32_t   st_blocks;  /* blocks allocated for file */
    __uint32_t  st_flags;   /* user defined flags for file */
    __uint32_t  st_gen;     /* file generation number */
};

#define __DARWIN_STRUCT_STAT64_TIMES \
    struct timespec st_atimespec;       /* time of last access */ \
    struct timespec st_mtimespec;       /* time of last data modification */ \
    struct timespec st_ctimespec;       /* time of last status change */ \
    struct timespec st_birthtimespec;   /* time of file creation(birth) */

#else /* (_POSIX_C_SOURCE && !_DARWIN_C_SOURCE) */

#define __DARWIN_STRUCT_STAT64_TIMES \
    time_t      st_atime;       /* [XSI] Time of last access */ \
    long        st_atimensec;       /* nsec of last access */ \
    time_t      st_mtime;       /* [XSI] Last data modification time */ \
    long        st_mtimensec;       /* last data modification nsec */ \
    time_t      st_ctime;       /* [XSI] Time of last status change */ \
    long        st_ctimensec;       /* nsec of last status change */ \
    time_t      st_birthtime;       /*  File creation time(birth)  */ \
    long        st_birthtimensec;   /* nsec of File creation time */

#endif /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */
leo-arch commented 10 months ago

10.6?! That's quite old, but it doesn't matter: we really want clifm running on everything. So, let's try to fix this.

Is your machine 32-bit?

barracuda156 commented 10 months ago

@leo-arch Thank you for responding! Yes, I build for ppc, which is only 32-bit on 10.6. (The last OS to support ppc64 is 10.5.8.)

leo-arch commented 10 months ago

Ok. The thing is that st_birthtimespec is a 64-bit extension. Try this: replace line 222 in helpers.h from this:

 #elif defined(__NetBSD__) || defined(__APPLE__)

to this:

 #elif defined(__NetBSD__) || (defined(__APPLE__) && !defined(__PPC__))

If your compiler supports the __PPC__ macro, we should be fine.

barracuda156 commented 10 months ago

@leo-arch Perfect, that worked! (We need it is small case for Apple though, __ppc__.)

This will, perhaps, be generally applicable:

--- src/helpers.h.orig  2023-07-18 20:44:17.000000000 +0800
+++ src/helpers.h       2023-08-25 22:16:29.000000000 +0800
@@ -219,7 +219,7 @@
  * actually store creation times: the value of __st_birthtim is always zero.
 #elif defined(__OpenBSD__)
 # define ST_BTIME __st_birthtim */
-#elif defined(__NetBSD__) || defined(__APPLE__)
+#elif defined(__NetBSD__) || (defined(__APPLE__) && !(defined(__ppc__) || defined(__i386__)))
 # define ST_BTIME st_birthtimespec
 #elif defined(__FreeBSD__) || defined(__CYGWIN__)
 # define ST_BTIME st_birthtim

P. S. Are colors like this intended? Yellow is barely readable. clifm

leo-arch commented 10 months ago

Great! Thanks for testing.

As to the colors, yes, those are the default colors (4-bit). However, the default color scheme is intended to be used with dark terminals (dark background). Try just switching your color scheme: cs light (you can also try the 256 colors version of the default color scheme: cs default-256). If you still do not find them comfortable enough, every single color is customizable. Take a look at the colors section in the wiki.

barracuda156 commented 10 months ago

@leo-arch Thank you! Noted.

By the way, maybe you could add the patch above into the master? It may help someone who builds clifm directly (without Macports), and also frees us from a need to carry a local patch :)

leo-arch commented 10 months ago

Already done @barracuda156! See c9a0a102f8d1388f59fe79625917cbc9f1ec276d.

leo-arch commented 10 months ago

Hey @barracuda156, what version of readline does Snow Leopard provide? The oldest version I've tried is 6.3 (2014, I think), but Snow Leopard is probably using something even older (5.2?).

barracuda156 commented 10 months ago

@leo-arch We have the latest one, I believe. Whatever Apple had at the time does not really matter, we can always use newer versions (technically, whatever Macports offers, but usually that is either the latest or latest feasible for the OS). However it may need to be specified in the portfile, to ensure the correct one is picked by the build.

leo-arch commented 10 months ago

Good to know. Thanks for your answer @barracuda156!