tools/gnulib: unmangle fts header on macOS

The gnulib fts header is meant to not be overwritten
in any way by the host system's copy of fts.h
and was therefore given a unique name instead.

This is fine if the built libgnu library is directly linked
with the target library, but if we want to keep them isolated
we end up having the definitions being mangled anyway
when the next object to link against included the fts.h header.

On some macOS platforms, the use of __DARWIN_INODE64
is messing with the link name for fts functions, resulting in:

Undefined symbols for architecture x86_64:
  "_rpl_fts_close$INODE64", referenced from:
...

Create a local fts header for gnulib
that completely blocks the macOS host fts header.

An alternative and more upstream friendly fix would be
to rename fts_.h to fts.h and add the macOS-only
include guard to that file within it's own include guard,
but that would be a massive patch, so do this for now.

Tested-by: Georgi Valkov <gvalkov@gmail.com> # macOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15368
Signed-off-by: Robert Marko <robimarko@gmail.com>

1 files changed, 19 insertions, 0 deletions

diff --git a/tools/gnulib/patches/120-unmangle-darwin-fts-h.patch b/tools/gnulib/patches/120-unmangle-darwin-fts-h.patch
new file mode 100644
index 0000000000..19e46b9103
--- /dev/null
+++ b/tools/gnulib/patches/120-unmangle-darwin-fts-h.patch
@@ -0,0 +1,19 @@
+--- /dev/null
++++ b/lib/fts.h
+@@ -0,0 +1,6 @@
++#ifdef __APPLE__
++# define _FTS_H_ 1
++# include <fts_.h>
++#else
++# include_next <fts.h>
++#endif
+--- a/modules/fts
++++ b/modules/fts
+@@ -2,6 +2,7 @@ Description:
+ Traverse a file hierarchy.
+ 
+ Files:
++lib/fts.h
+ lib/fts_.h
+ lib/fts.c
+ lib/fts-cycle.c