On 15.12.2023 13:23, Florian Weimer wrote:
> * Jan Beulich:
>
>> On 15.12.2023 12:59, Florian Weimer wrote:
>>> The cc-option check always fails (that, it picks the second option
>>> unconditionally) if the compiler does not support implicit conversion
>>> from integers to pointers. Just drop the initialization because it
>>> seems unnecessary in this context.
>>
>> Did you pay attention to ...
>>
>>> --- a/Config.mk
>>> +++ b/Config.mk
>>> @@ -21,7 +21,7 @@ endef
>>> # of which would indicate an "unrecognized command-line option"
>>> warning/error.
>>
>> ... the comment the tail of which is visible here?
>
> I didn't investigate how the mechanics of the selection are
> accomplished. I was so happy that I finally found the source of the
> int-conversion error and got a bit carried away.
>
> Looking at the shell script fragment:
>
>>> # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586)
>>> -cc-option = $(shell if test -z "`echo 'void*p=1;' | \
>>> +cc-option = $(shell if test -z "`echo 'void*p;' | \
>>> $(1) $(2) -c -o /dev/null -x c - 2>&1 | grep -- $(2) -`"; \
>>> then echo "$(2)"; else echo "$(3)"; fi ;)
>
> I can see that the exit status of the compiler does not matter, so the
> patch will not make a difference.
An option may be to use Xen's (newer) variant
cc-option = $(shell if $(1) $(2:-Wno-%=-W%) -Werror -c -o /dev/null -x c
/dev/null >/dev/null 2>&1; \
then echo "$(2)"; else echo "$(3)"; fi ;)
here as well (omitted all commentary). Cc-ing maintainers for possible
input.
Jan
