From: Andreas Ziegler <br015@umbiko.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/gcc: undefine NDEBUG directive
Date: Mon, 21 Jun 2021 04:49:50 +0000 [thread overview]
Message-ID: <f62466d58c976ffb7a267bbc3e20f6ce@umbiko.net> (raw)
In-Reply-To: <ef698263-7720-7db2-8f4b-7d1cf1e4fbe9@gmail.com>
Bonjour Romain,
On 2021-06-20 18:23, Romain Naour wrote:
> Hello Andreas,
>
> Le 17/06/2021 ? 14:19, Andreas Ziegler a ?crit?:
>> GCC performs internal consistency checks that can be controlled with
>> --enable-checking, but not completely removed for all stages of the
>> build. One of these checks uses the assert macro from <assert.h>
>> Defining NDEBUG removes the assertion code, which is not anticipated
>> in the gcc code.
>>
>> Undefine the NDEBUG flag for package/gcc to preserve assertions.
>>
>> This fixes the following error during build of GCC 10:
>>
>> ../../../libgomp/target.c: In function ?gomp_unmap_vars_internal?:
>> ../../../libgomp/target.c:1474:9: error: unused variable
>> ?is_tgt_unmapped? [-Werror=unused-variable]
>> 1474 | bool is_tgt_unmapped = gomp_remove_var (devicep, k);
>> | ^~~~~~~~~~~~~~~
>> ../../../libgomp/target.c:1473:28: error: unused variable ?k_tgt?
>> [-Werror=unused-variable]
>> 1473 | struct target_mem_desc *k_tgt = k->tgt;
>> | ^~~~~
>
> It seems an error related to Werror being enabled.
>
> Usually we prefer disable Werror while building a package in Buildroot
> because
> any package can trigger new warning with the latest compiler.
Using -Wno-error was my first idea, though I would have preferred to
just disable the actual error: -Werror=unused-variable. I posted a
question an the mailing list
https://marc.info/?l=buildroot&m=162366255526973&w=2
After receiving no answer, I did some more research:
-- gcc does not use NDEBUG consistently, but relies on assertions to
monitor some internal structures. These assertions, but not the code,
are disabled via the C library when NDEBUG is set.
-- The build process explicitly sets -Werror in some phases.
-- For enabling and disabling individual internal checks and assertions,
configure options exist:
--enable-werror
--disable-werror
--enable-checking
--disable-checking
--disable-stage1-checking
--enable-stage1-checking
So my recommendation is to remove NDEBUG, not suppress the error
message. This is the least invasive option.
> Maybe we can use -Wno-error not just when BR2_ENABLE_DEBUG is set:
>
> https://git.buildroot.net/buildroot/commit/?id=dcaf6e75acb4d21c2c31c70b054dac8d18710fcb
I have seen this, but would not recommend disabling errors overall to
catch one specific error that manifests. -Wno-error=maybe-uninitialized
might have been more elegant ...
Kind regards,
Andreas
> Best regards,
> Romain
>
>>
>> Signed-off-by: Andreas Ziegler <br015@umbiko.net>
>> ---
>> package/gcc/gcc.mk | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
>> index ed9b93e50f..4ee32c03a7 100644
>> --- a/package/gcc/gcc.mk
>> +++ b/package/gcc/gcc.mk
>> @@ -90,7 +90,8 @@ HOST_GCC_COMMON_CONF_OPTS = \
>> HOST_GCC_COMMON_CONF_ENV = \
>> MAKEINFO=missing
>>
>> -GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
>> +# gcc should not be built with NDEBUG enabled
>> +GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS) -UNDEBUG
>> GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)
>>
>> # used to fix
>> ../../../../libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
>> error: 'st.st_mode' may be used uninitialized in this function
>> [-Werror=maybe-uninitialized]
>>
next prev parent reply other threads:[~2021-06-21 4:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 12:19 [Buildroot] [PATCH 1/1] package/gcc: undefine NDEBUG directive Andreas Ziegler
2021-06-20 18:23 ` Romain Naour
2021-06-21 4:49 ` Andreas Ziegler [this message]
2021-07-04 19:58 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f62466d58c976ffb7a267bbc3e20f6ce@umbiko.net \
--to=br015@umbiko.net \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox