Carlo Arenas [off-list ref] writes:
On Mon, Sep 27, 2021 at 4:04 PM Jonathan Tan [off-list ref] wrote:
quoted
quoted
+ifneq ($(filter gcc5,$(COMPILER_FEATURES)),)
+DEVELOPER_CFLAGS += -Wno-incompatible-pointer-types
+endif
I noticed today that I wasn't warned about some incompatible function
pointer signatures (that I expected to be warned about) due to this
line - could the condition of adding this compiler flag be further
narrowed down? gcc -v says:
Apologies; it is gone already in "seen" (and hopefully soon in "next")
by merging js/win-lazyload-buildfix[1]
I will mark it not ready for 'next', while waiting for a fix-up.
Thanks for stopping me.
Carlo Arenas [off-list ref] writes:
quoted
On Mon, Sep 27, 2021 at 4:04 PM Jonathan Tan [off-list ref] wrote:
quoted
quoted
+ifneq ($(filter gcc5,$(COMPILER_FEATURES)),)
+DEVELOPER_CFLAGS += -Wno-incompatible-pointer-types
+endif
I noticed today that I wasn't warned about some incompatible function
pointer signatures (that I expected to be warned about) due to this
line - could the condition of adding this compiler flag be further
narrowed down? gcc -v says:
Apologies; it is gone already in "seen" (and hopefully soon in "next")
by merging js/win-lazyload-buildfix[1]
I will mark it not ready for 'next', while waiting for a fix-up.
Thanks for stopping me.
Just checking - which branch is not ready for next? The issue I noticed
is already in master, and js/win-lazyload-buildfix contains the fix for
the issue (which ideally would be merged as soon as possible, but
merging according to the usual schedule is fine).
On Tue, Sep 28, 2021 at 1:16 PM Jonathan Tan [off-list ref] wrote:
quoted
Carlo Arenas [off-list ref] writes:
quoted
Apologies; it is gone already in "seen" (and hopefully soon in "next")
by merging js/win-lazyload-buildfix[1]
I will mark it not ready for 'next', while waiting for a fix-up.
Thanks for stopping me.
Just checking - which branch is not ready for next? The issue I noticed
is already in master, and js/win-lazyload-buildfix contains the fix for
the issue (which ideally would be merged as soon as possible, but
merging according to the usual schedule is fine).
My guess was that he meant to have also the windows specific check
added as part of this branch, and that would have prevented the issue
you reported originally as well.
Either way, a v4 has been posted[1] (sorry, forgot to CC you), and
hopefully that is now ready for next ;)
Carlo
[1] https://lore.kernel.org/git/20210929004832.96304-1-carenas@gmail.com/