Question about ancient TARGET_CFLAGS in rules.mk?

[Christian Marangi]

On Sun, Jul 17, 2022 at 01:48:41AM +0200, Ansuel Smith wrote:
> Hi,
> some background about this.
> 
> I'm trying to improve our CI system more and more by finally adding
> support for real
> EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI
> to make sure everything works and all compiles correctly...
> 
> While testing it I notice a specific target fails to compile ubox package.
> While still to investigate why this is only present on that target, i
> found out why
> this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build.
> 
> The error is this
> 
> kmodloader.c: In function 'main_loader':
> 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf'
> declared with attribute 'warn_unused_result' [-Werror=unused-result]
> 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] Error 1
> 1341 1027 | asprintf(&m->opts, "%s %s", prev, opts);
> 1342 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1343cc1: all warnings being treated as errors
> 
> The package is compiled with -Wall so it does make sense that the
> error is printed...
> 
> Fact is that the error(warning) is actually correct but I couldn't
> understand why it was
> not flagged on normal build and here the reason...
> 
> In rules.mk we have
> TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable
> -Wno-error=unused-result
> and this is only applied if EXTERNAL_TOOLCHAIN is not selected...
> 
> Now the question... WHY?
> 
> Considering even the linux kernel started to use Wall by default,
> should we also start
> enforcing correct code and fix every package that present such error?
> Fixing these kind of error is trivial enough and IMHO we should drop these
> warning disable.
> 
> I will create a PR in the next few days but wonder if anyone wants to
> give some feedback
> about why these extra flags are set. To me it seems they are just
> leftover from older times?

For everyone interested... I create a pr [1] if someone prefer to continue
the discussion on github

[1] https://github.com/openwrt/openwrt/pull/10291

-- 
	Ansuel