Defining strlcpy here clashes on macOS, which has some compiler magic
around their strlcpy declaration. Fix this by inverting the check
to declare the prototype only if we are on __GLIBC__. As uClibc may
define __GLIBC__ as well, check for absence of its __UCLIBC__.
This is in-line with what Linux has been doing since 0215d59b15
("tools lib: Reinstate strlcpy() header guard with __UCLIBC__").
Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
---
scripts/include/linux/string.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/include/linux/string.h b/scripts/include/linux/string.h
index e26223f1f287..649287b80a8c 100644
--- a/scripts/include/linux/string.h
+++ b/scripts/include/linux/string.h
@@ -8,7 +8,11 @@ void *memdup(const void *src, size_t len);
int strtobool(const char *s, bool *res);
-#ifndef __UCLIBC__
+/*
+ * glibc based builds needs the extern while uClibc doesn't.
+ * However uClibc headers also define __GLIBC__ hence the hack below
+ */
+#if defined(__GLIBC) && !defined(__UCLIBC__)
extern size_t strlcpy(char *dest, const char *src, size_t size);
#endif
--
2.20.1
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
