tools/gnulib: unmangle fts header on macOS
authorMichael Pratt <mcpratt@pm.me>
Sun, 5 May 2024 07:42:44 +0000 (03:42 -0400)
committerRobert Marko <robimarko@gmail.com>
Fri, 31 May 2024 14:01:43 +0000 (16:01 +0200)
commit37f20d8c34f04253037c03513e3a4d67b5f242da
tree669fad6984dced7c6407ecbfb83134e4ee2e3606
parenta39d9693e66dea73d9753c7c0bae1378c2e97fed
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>
tools/gnulib/patches/120-unmangle-darwin-fts-h.patch [new file with mode: 0644]