High CPU use on BTRFS and some other details in the stable release package.

[Steve]

I'm not sure what was at fault here but I had excessive CPU use with findutils 
after switching from EXT4 to BTRFS in Void Linux.
https://github.com/voidlinux/void-packages/issues/4829
Is this because find isn't optimised for BTRFS, there's a problem with the 
BTRFS kernel driver, or something else? I built the latest version of findutils 
from the stable source package and had the same result. I resolved my personal 
requirements by switching to using mlocate and ag instead, but also saw some 
other small errors in the source package. Perhaps these other observations 
might be helpful for you?

 File: README-alpha : Says it's an alpha release when it's the latest stable 
one.
 The entire ChangeLog-2013 content is duplicated in ChangeLog
 Typo:  README-hacking: "Dejagnu is in fact optional, but it's strongly 
recommened,"

Compiles in a standard build, but won't build debug version:
findutils-4.6.0$ ./configure --enable-debug
$ make

ftsfind.c: In function 'main':
ftsfind.c:705:49: warning: passing argument 1 of 'ctime' from incompatible 
pointer type
   fprintf (stderr, "cur_day_start = %s", ctime (&options.cur_day_start));
                                                 ^
In file included from ../gl/lib/time.h:41:0,
                 from ../gl/lib/sys/stat.h:44,
                 from ftsfind.c:39:
/usr/include/time.h:264:14: note: expected 'const time_t *' but argument is of 
type 'struct timespec *'
 extern char *ctime (const time_t *__timer) __THROW;
              ^

Fixed that error:

 find/ftsfind.c

#ifdef DEBUG
  fprintf (stderr, "cur_day_start = %s", ctime (&options.cur_day_start));
#endif /* DEBUG */

Changed to:
  fprintf (stderr, "cur_day_start = %s", ctime ((time_t 
*)&options.cur_day_start.tv_sec));


But it seems to have an outdated binary which is only called in a debug build:
mv -f .deps/ftsfind.Tpo .deps/ftsfind.Po
gcc -std=gnu99  -g -O2   -o find ftsfind.o ./libfindtools.a ../lib/libfind.a 
../gl/lib/libgnulib.a       -lm -lm
../gl/lib/libgnulib.a(parse-datetime.o): In function `parse_datetime':
/home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/parse-datetime.y:1452:
 undefined reference to `rpl_mktime'
/home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/parse-datetime.y:1484:
 undefined reference to `rpl_mktime'
/home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/parse-datetime.y:1497:
 undefined reference to `rpl_mktime'
/home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/parse-datetime.y:1519:
 undefined reference to `rpl_mktime'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:1810: find] Error 1
make[3]: Leaving directory 
'/home/steve/projects/gnu-findutils/2dbg/findutils-4.6.0/find'
make[2]: *** [Makefile:1898: all-recursive] Error 1
make[2]: Leaving directory 
'/home/steve/projects/gnu-findutils/2dbg/findutils-4.6.0/find'
make[1]: *** [Makefile:1706: all-recursive] Error 1
make[1]: Leaving directory 
'/home/steve/projects/gnu-findutils/2dbg/findutils-4.6.0'
make: *** [Makefile:1646: all] Error 2

The source is different:
gl/lib/parse-datetime.y
1452      Start = mktime (&tm);
1484              Start = mktime (&tm);
1497          Start = mktime (&tm);
1519          Start = mktime (&tm);

make only updates what it needs to, probably the stable package didn't get 
built from a clean source. (Sometimes make clean misses stuff too.)
Building from git repo would probably fix this, I didn't try that.
Steve.