[dev] [ii] fails to build on systems with strlcpy

[Misty De Meo]

Commit 704ab925e92097778821d36954699f665028254d of ii added a bundled
copy of strlcpy. Unfortunately this broke the build on OSs that
provide strlcpy, like Mac OS X. It would be great if this could be
fixed either by making the usage of strlcpy dependent on something
configured in config.mk, or by renaming ii's definition of it.

Best,
Misty

[Hiltjo Posthuma]

Post by Misty De Meo
Commit 704ab925e92097778821d36954699f665028254d of ii added a bundled
copy of strlcpy. Unfortunately this broke the build on OSs that
provide strlcpy, like Mac OS X. It would be great if this could be
fixed either by making the usage of strlcpy dependent on something
configured in config.mk, or by renaming ii's definition of it.
Best,
Misty

What is the output of the compiler? Can you give more information what is
broken exactly?

It works for me on OpenBSD.

[Misty De Meo]

On Mon, May 28, 2018 at 11:40 PM, Hiltjo Posthuma

Post by Hiltjo Posthuma
What is the output of the compiler? Can you give more information what is
broken exactly?
It works for me on OpenBSD.

I'm using clang on Mac OS X 10.13. It fails with the following errors:

cc -c -o strlcpy.o strlcpy.c -Os -I. -I/usr/include -DVERSION=\"1.8\"
-std=c99 -D_DEFAULT_SOURCE
strlcpy.c:11:1: error: expected parameter declarator
strlcpy(char *dst, const char *src, size_t siz)
^
/usr/include/secure/_string.h:108:47: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object,
_USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
/usr/include/secure/_common.h:30:32: note: expanded from macro
'_USE_FORTIFY_LEVEL'
# define _USE_FORTIFY_LEVEL 2
^
strlcpy.c:11:1: error: expected ')'
/usr/include/secure/_string.h:108:47: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object,
_USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
/usr/include/secure/_common.h:30:32: note: expanded from macro
'_USE_FORTIFY_LEVEL'
# define _USE_FORTIFY_LEVEL 2
^
strlcpy.c:11:1: note: to match this '('
/usr/include/secure/_string.h:108:47: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object,
_USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
strlcpy.c:11:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
strlcpy(char *dst, const char *src, size_t siz)
^
/usr/include/secure/_string.h:108:47: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object,
_USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
strlcpy.c:11:1: error: conflicting types for '__builtin___strlcpy_chk'
/usr/include/secure/_string.h:108:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
strlcpy.c:11:1: note: '__builtin___strlcpy_chk' is a builtin with type
'unsigned long (char *, const char *,
unsigned long, unsigned long)'
/usr/include/secure/_string.h:108:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
strlcpy.c:11:1: error: definition of builtin function '__builtin___strlcpy_chk'
strlcpy(char *dst, const char *src, size_t siz)
^
/usr/include/secure/_string.h:108:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, __VA_ARGS__,
__darwin_obsz (dest))
^
1 warning and 4 errors generated.

[Manu Raster]

Strlcpy works fine with Linux and gcc, too. It's probably just a clang
or apple bug.

[Tobias Tschinkowitz]

Post by Manu Raster
Strlcpy works fine with Linux and gcc, too. It's probably just a clang
or apple bug.

Build works fine over here...
OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM
6.0.0)

Greetings,
Tobias

[Misty De Meo]

Post by Manu Raster
Strlcpy works fine with Linux and gcc, too. It's probably just a clang
or apple bug.

I don't believe it's a clang bug, but just that the strlcpy definition
clashes with the macro which is imported via <string.h>. (OS X defines
both a C function and a macro by the same name which wraps it, at
least at FORTIFY_SOURCE levels above 0.) I notice that iic does #undef
strlcpy before the prototype definition, but strlcpy.c does not.
Adding that allows ii to build for me.

[Manu Raster]

Post by Misty De Meo

Post by Manu Raster
Strlcpy works fine with Linux and gcc, too. It's probably just a clang
or apple bug.

I don't believe it's a clang bug, but just that the strlcpy definition
clashes with the macro which is imported via <string.h>. (OS X defines
both a C function and a macro by the same name which wraps it, at
least at FORTIFY_SOURCE levels above 0.) I notice that iic does #undef
strlcpy before the prototype definition, but strlcpy.c does not.
Adding that allows ii to build for me.

Very well! Problem solved and this indeed helps dealing easier with mac
people when needed. (Windows people have a native win32 port of dwm
instead.)

BR
Manu

[Hiltjo Posthuma]

Post by Misty De Meo
Commit 704ab925e92097778821d36954699f665028254d of ii added a bundled
copy of strlcpy. Unfortunately this broke the build on OSs that
provide strlcpy, like Mac OS X. It would be great if this could be
fixed either by making the usage of strlcpy dependent on something
configured in config.mk, or by renaming ii's definition of it.
Best,
Misty

Hi,

Can you retry and see if the latest ii commit fixes the issue for you?

See the bottom of the config.mk file.

[Misty De Meo]

Post by Hiltjo Posthuma
Hi,
Can you retry and see if the latest ii commit fixes the issue for you?
See the bottom of the config.mk file.

That did the trick - thanks very much!