On Sat, Dec 19, 2020 at 12:33 AM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>
>
> On 18/12/2020 15:12, Jon Hunter wrote:
> >
> > On 18/12/2020 15:09, Marek Szyprowski wrote:
> >>
> >> On 18.12.2020 16:03, Jon Hunter wrote:
> >>> On 18/12/2020 10:05, Marek Szyprowski wrote:
> >>>> On 18.12.2020 10:43, Masahiro Yamada wrote:
> >>>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski
> >>>>> <m.szyprowski@xxxxxxxxxxx> wrote:
> >>>>>> On 03.12.2020 13:57, Masahiro Yamada wrote:
> >>>>>>> Linus pointed out a third of the time in the Kconfig parse stage comes
> >>>>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1],
> >>>>>>> and directly testing plugin-version.h for existence cuts down the
> >>>>>>> overhead a lot. [2]
> >>>>>>>
> >>>>>>> This commit takes one step further to kill the build test entirely.
> >>>>>>>
> >>>>>>> The small piece of code was probably intended to test the C++ designated
> >>>>>>> initializer, which was not supported until C++20.
> >>>>>>>
> >>>>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning.
> >>>>>>>
> >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only
> >>>>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic]
> >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only
> >>>>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator]
> >>>>>>> class test { public: int test; } test = { .test = 1 };
> >>>>>>> ^
> >>>>>>> 1 warning generated.
> >>>>>>>
> >>>>>>> Otherwise, modern C++ compilers should be able to build the code, and
> >>>>>>> hopefully skipping this test should not make any practical problem.
> >>>>>>>
> >>>>>>> Checking the existence of plugin-version.h is still needed to ensure
> >>>>>>> the plugin-dev package is installed. The test code is now small enough
> >>>>>>> to be embedded in scripts/gcc-plugins/Kconfig.
> >>>>>>>
> >>>>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F
> >>>>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F
> >>>>>>>
> >>>>>>> Reported-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> >>>>>>> Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
> >>>>>> This patch landed in linux next-20201217 as commit 1e860048c53e
> >>>>>> ("gcc-plugins: simplify GCC plugin-dev capability test").
> >>>>>>
> >>>>>> It causes a build break with my tests setup, but I'm not sure weather it
> >>>>>> is really an issue of this commit or a toolchain I use. However I've
> >>>>>> checked various versions of the gcc cross-compilers released by Linaro
> >>>>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all
> >>>>>> fails with the same error:
> >>>>>>
> >>>>>> $ make ARCH=arm
> >>>>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi-
> >>>>>> zImage
> >>>>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so
> >>>>>> In file included from
> >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0,
> >>>>>> from scripts/gcc-plugins/gcc-common.h:7,
> >>>>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
> >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10:
> >>>>>> fatal error: gmp.h: No such file or directory
> >>>>>> #include <gmp.h>
> >>>>>> ^~~~~~~
> >>>>>> compilation terminated.
> >>>>>> scripts/gcc-plugins/Makefile:47: recipe for target
> >>>>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed
> >>>>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1
> >>>>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed
> >>>>>> make[1]: *** [scripts/gcc-plugins] Error 2
> >>>>>> Makefile:1190: recipe for target 'scripts' failed
> >>>>>> make: *** [scripts] Error 2
> >>>>>>
> >>>>>> Compilation works if I use the cross-gcc provided by
> >>>>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is:
> >>>>>>
> >>>>>> $ arm-linux-gnueabi-gcc --version
> >>>>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
> >>>>>>
> >>>>> I can compile gcc-plugins with Linaro toolchians.
> >>>>>
> >>>>> The version of mine is this:
> >>>>>
> >>>>> masahiro@oscar:~/ref/linux-next$
> >>>>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version
> >>>>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0
> >>>>> Copyright (C) 2017 Free Software Foundation, Inc.
> >>>>> This is free software; see the source for copying conditions. There is NO
> >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Maybe, it depends on the host environment?
> >>>>>
> >>>>>
> >>>>> Please try this:
> >>>>>
> >>>>> $ sudo apt install libgmp-dev
> >>>> Indeed, it was missing on my setup. Sorry for the noise.
> >>>
> >>> So this change also breaks the build on our farm build machines and
> >>> while we can request that packages are installed on these machines, it
> >>> takes time. Is there anyway to avoid this?
> >>
> >> You can temporarily revert 1e860048c53e (this patch).
> >
> >
> > Again that works locally, but these automated builders just pull the
> > latest -next branch and build.
>
>
> However, if you are saying that this is a problem/bug with our builders,
> then of course we will have to get this fixed.
>
Yes, please do so.
Kconfig evaluates $(CC) capabilities, and
hides CONFIG options it cannot support.
In contrast, we do not do that for $(HOSTCC)
capabilities because it is just a matter of some
missing packages.
For example, if you enable CONFIG_SYSTEM_TRUSTED_KEYRING
and fail to build scripts/extrace-cert.c
due to missing <openssl/bio.h>,
you need to install the openssl dev package.
It is the same pattern.
--
Best Regards
Masahiro Yamada
