From 37f20d8c34f04253037c03513e3a4d67b5f242da Mon Sep 17 00:00:00 2001 From: Michael Pratt Date: Sun, 5 May 2024 03:42:44 -0400 Subject: [PATCH] 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 # macOS Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/15368 Signed-off-by: Robert Marko --- .../patches/120-unmangle-darwin-fts-h.patch | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 tools/gnulib/patches/120-unmangle-darwin-fts-h.patch 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 ++#else ++# include_next ++#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 -- 2.30.2