By the way, it didn't warn with GCC 4.9 and before, but it does not return 0: https://godbolt.org/z/Ecq89Tqdn So I bet that the warning was always there and redirecting GCC's output was just a way to hide the warnings. Which is, IMHO, way harder and a lot less obvious than just producing a correct test code that has no warning to start with.
Le lun. 22 juil. 2024 à 07:54, Nop <ctx...@gmail.com> a écrit : > > My english can be clunky so I'll let you rephrase the message as you wish. > > I'm not saying that the issue GCC output being redirected. I'm saying > that redirecting GCC's output hides the real issue. Because all the > use can see it the message about missing ncurses, while ncurses has > nothing to do with the issue. > That is why I removed the redirection, to avoid future useless error tracking. > > The real issue is the test code being wrong: the main should have > explicit 'int' return. It was a warning prior gcc 14.1. It should have > been fixed when it was a warning, but nobody seen it because it was > hidden. It is a warning since at least gcc 5... > See: https://godbolt.org/z/G6zaEzn1f > > I did not search how buildroot and linux fixed the issue of their > side. IMHO the buildroot fix is not enough: > - It still hides potential issues > - There is no "return 0;" statement. I know this is allowed, but it is > not explicit and I would not be surprised if someday a warning is > added about that. So I would not remove it for the sole purpose of > saving 10 bytes of code. > > Le dim. 21 juil. 2024 à 20:09, Harald van Dijk <har...@gigawatt.nl> a écrit : > > > > On 21/07/2024 13:10, Nop wrote: > > > Newer GCC increased diagnostics levels resulting in considering the test > > > code to be invalid. The resulting message was misleading, saying that > > > ncurses is not found, while it is actually found because GCC output is > > > redirected to /dev/null. > > > > Hi, > > > > This explanation does not look correct. GCC output being redirected has > > nothing to do with whether ncurses can or cannot be found, GCC output > > being redirected only means the reason why ncurses cannot be found gets > > hidden. In buildroot, the same error was fixed while keeping the > > 2>/dev/null: > > > > https://github.com/buildroot/buildroot/blob/a6210d28dbf66b2f0a42d945711dfd93c7329feb/support/kconfig/patches/22-kconfig-lxdialog-fix-check-with-GCC14.patch > > > > In Linux, this problem was avoided because the check was changed to not > > do compilation of a test program at all (preferring pkg-config instead): > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch?id=1c5af5cf9308fff327f52c7efd2dfa732d370871 > > > > Cheers, > > Harald van Dijk > > > > > Signed-off-by: ctxnop <ctx...@gmail.com> > > > --- > > > scripts/kconfig/lxdialog/check-lxdialog.sh | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh > > > b/scripts/kconfig/lxdialog/check-lxdialog.sh > > > index 5075ebf2d..c644d1d48 100755 > > > --- a/scripts/kconfig/lxdialog/check-lxdialog.sh > > > +++ b/scripts/kconfig/lxdialog/check-lxdialog.sh > > > @@ -45,9 +45,9 @@ trap "rm -f $tmp" 0 1 2 3 15 > > > > > > # Check if we can link to ncurses > > > check() { > > > - $cc -x c - -o $tmp 2>/dev/null <<'EOF' > > > + $cc -x c - -o $tmp <<'EOF' > > > #include CURSES_LOC > > > -main() {} > > > +int main() { return 0; } > > > EOF > > > if [ $? != 0 ]; then > > > echo " *** Unable to find the ncurses libraries or the" > > > 1>&2 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
