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://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/
[2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/
Reported-by: Linus Torvalds <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
---
scripts/gcc-plugin.sh | 19 -------------------
scripts/gcc-plugins/Kconfig | 2 +-
2 files changed, 1 insertion(+), 20 deletions(-)
delete mode 100755 scripts/gcc-plugin.sh
diff --git a/scripts/gcc-plugin.sh b/scripts/gcc-plugin.sh
deleted file mode 100755
index b79fd0bea838..000000000000
--- a/scripts/gcc-plugin.sh
+++ /dev/null
@@ -1,19 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-
-set -e
-
-srctree=$(dirname "$0")
-
-gccplugins_dir=$($* -print-file-name=plugin)
-
-# we need a c++ compiler that supports the designated initializer GNU extension
-$HOSTCC -c -x c++ -std=gnu++98 - -fsyntax-only -I $srctree/gcc-plugins -I $gccplugins_dir/include 2>/dev/null <<EOF
-#include "gcc-common.h"
-class test {
-public:
- int test;
-} test = {
- .test = 1
-};
-EOF
diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
index ae19fb0243b9..ab9eb4cbe33a 100644
--- a/scripts/gcc-plugins/Kconfig
+++ b/scripts/gcc-plugins/Kconfig
@@ -9,7 +9,7 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on CC_IS_GCC
- depends on $(success,$(srctree)/scripts/gcc-plugin.sh $(CC))
+ depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)
default y
help
GCC plugins are loadable modules that provide extra features to the
--
2.27.0
On Thu, Dec 3, 2020 at 5:03 AM Masahiro Yamada <[email protected]> wrote:
>
> 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.
Ack. I think the "plugin" directory name should be quoted, but that's
a pre-existing bug.
Linus
On Thu, Dec 03, 2020 at 09:57:00PM +0900, 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://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/
> [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/
>
> Reported-by: Linus Torvalds <[email protected]>
> Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Kees Cook <[email protected]>
--
Kees Cook
On Thu, 3 Dec 2020 21:57:00 +0900, 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.
>
> [...]
Applied to for-next/gcc-plugins, thanks!
[1/1] gcc-plugins: simplify GCC plugin-dev capability test
https://git.kernel.org/kees/c/1e860048c53e
--
Kees Cook
Hi,
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://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/
> [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/
>
> Reported-by: Linus Torvalds <[email protected]>
> Signed-off-by: Masahiro Yamada <[email protected]>
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://releases.linaro.org/components/toolchain/binaries/ 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
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski
<[email protected]> wrote:
>
> Hi,
>
> 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://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/
> > [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/
> >
> > Reported-by: Linus Torvalds <[email protected]>
> > Signed-off-by: Masahiro Yamada <[email protected]>
>
> 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://releases.linaro.org/components/toolchain/binaries/ 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
>
> Best regards
>
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
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
--
Best Regards
Masahiro Yamada
On 18.12.2020 10:43, Masahiro Yamada wrote:
> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski
> <[email protected]> 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 <[email protected]>
>>> Signed-off-by: Masahiro Yamada <[email protected]>
>> 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.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
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
>> <[email protected]> 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 <[email protected]>
>>>> Signed-off-by: Masahiro Yamada <[email protected]>
>>> 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?
Cheers
Jon
--
nvpublic
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
>>> <[email protected]> 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 <[email protected]>
>>>>> Signed-off-by: Masahiro Yamada <[email protected]>
>>>> 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).
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
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
>>>> <[email protected]> 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 <[email protected]>
>>>>>> Signed-off-by: Masahiro Yamada <[email protected]>
>>>>> 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.
Jon
--
nvpublic
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
>>>>> <[email protected]> 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 <[email protected]>
>>>>>>> Signed-off-by: Masahiro Yamada <[email protected]>
>>>>>> 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.
Jon
--
nvpublic
On Sat, Dec 19, 2020 at 12:33 AM Jon Hunter <[email protected]> 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
> >>>>> <[email protected]> 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 <[email protected]>
> >>>>>>> Signed-off-by: Masahiro Yamada <[email protected]>
> >>>>>> 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
On 18/12/2020 15:42, Masahiro Yamada wrote:
...
>> 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.
OK, thanks for confirming. We will get this fixed.
Cheers Jon
--
nvpublic
On Sat, Dec 19, 2020 at 12:42:51AM +0900, Masahiro Yamada wrote:
> On Sat, Dec 19, 2020 at 12:33 AM Jon Hunter <[email protected]> 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
> > >>>>> <[email protected]> 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 <[email protected]>
> > >>>>>>> Signed-off-by: Masahiro Yamada <[email protected]>
> > >>>>>> 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.
I did notice that your patch changes the original check from using
$HOSTCC to try and build a test plugin using the gcc-plugin.h header
found using $CC to just determining the the existence of the
gcc-plugin.h header using $CC. So it's no longer trying to actually
use the gcc-plugin.h header.
I think that might be what's causing the builders to suddenly break.
Where previously the check would fail (presumably producing a similar
error to the one we're now seeing, i.e. $CC was built with plugins
support, but the installation was broken, so it can't actually build
plugins because some headers are missing) the same check now succeeds
(i.e. $CC was built with plugins support, but we no longer check if the
plugin support is also functional). That means after your change the
builders will now by default try to build the plugins and fail, whereas
previously they wouldn't attempt to do so because the dependency wasn't
met.
This is similar to what autotools does when it checks for headers. It
does one pass that just checks if a header is present and another pass
where it checks that the header can actually be used. Usually when the
first pass succeeds and the latter fails, it indicates that something is
wrong with your toolchain setup, or you didn't pass the proper arguments
in CFLAGS and friends.
So that makes the new check a bit less useful than the old one, because
rather than defaulting to "no" when GCC plugins can't be built, we now
default to "yes" when they should be able to get built but can't.
Anyway, it's probably reasonable to expect the installation to be good
and that plugins can be built if the gcc-plugin.h header can be found,
so I'm not objecting to this patch. However, I'm curious as to whether
installing libgmp-dev (and apparently libmpc-dev as well) is the right
thing to do here.
In case where CC != HOSTCC, it's possible that CC was not built against
the same version of GMP/MPC as HOSTCC. And even HOSTCC might not
necessarily have been built against the versions provided by libgmp-dev
or libmpc-dev. I'm not overly familiar with GMP/MPC, so perhaps if these
headers are reasonably stable, this is not all that important. But if it
is, then which version of GMP/MPC do we need? The version that CC was
built against, or the version that HOSTCC was built against?
Thierry
On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <[email protected]> wrote:
>
> However, if you are saying that this is a problem/bug with our builders,
> then of course we will have to get this fixed.
This seems to be a package dependency problem with the gcc plugins -
they clearly want libgmp, but apparently the package hasn't specified
that dependency.
If this turns out to be a big problem, I guess we can't simplify the
plugin check after all.
We historically just disabled gcc-plugins if that header didn't build,
which obviously meant that it "worked" for people, but it also means
that clearly the coverage can't have been as good as it could/should
be.
So if it's as simple as just installing the GNU multiprecision
libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most
debian systems), then I think that's the right thing to do. You'll get
a working build again, and equally importantly, your build servers
will actually do a better job of covering the different build options.
Linus
On 18/12/2020 17:54, Linus Torvalds wrote:
> On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <[email protected]> wrote:
>>
>> However, if you are saying that this is a problem/bug with our builders,
>> then of course we will have to get this fixed.
>
> This seems to be a package dependency problem with the gcc plugins -
> they clearly want libgmp, but apparently the package hasn't specified
> that dependency.
>
> If this turns out to be a big problem, I guess we can't simplify the
> plugin check after all.
>
> We historically just disabled gcc-plugins if that header didn't build,
> which obviously meant that it "worked" for people, but it also means
> that clearly the coverage can't have been as good as it could/should
> be.
>
> So if it's as simple as just installing the GNU multiprecision
> libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most
> debian systems), then I think that's the right thing to do. You'll get
> a working build again, and equally importantly, your build servers
> will actually do a better job of covering the different build options.
Thanks. I have reported this issue to the team that administers the
builders. So hopefully, they will install the necessary packages for us
now.
Cheers
Jon
--
nvpublic
On Fri, Dec 18, 2020 at 08:33:37PM +0000, Jon Hunter wrote:
>
> On 18/12/2020 17:54, Linus Torvalds wrote:
> > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <[email protected]> wrote:
> >>
> >> However, if you are saying that this is a problem/bug with our builders,
> >> then of course we will have to get this fixed.
> >
> > This seems to be a package dependency problem with the gcc plugins -
> > they clearly want libgmp, but apparently the package hasn't specified
> > that dependency.
> >
> > If this turns out to be a big problem, I guess we can't simplify the
> > plugin check after all.
> >
> > We historically just disabled gcc-plugins if that header didn't build,
> > which obviously meant that it "worked" for people, but it also means
> > that clearly the coverage can't have been as good as it could/should
> > be.
> >
> > So if it's as simple as just installing the GNU multiprecision
> > libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most
> > debian systems), then I think that's the right thing to do. You'll get
> > a working build again, and equally importantly, your build servers
> > will actually do a better job of covering the different build options.
>
>
> Thanks. I have reported this issue to the team that administers the
> builders. So hopefully, they will install the necessary packages for us
> now.
Just to close the loop on this, the builders now have libgmp-dev and
libmpc-dev packages installed and the builds are passing without the
workaround we had used.
Thierry
On Wed, Jan 20, 2021 at 2:48 AM Thierry Reding <[email protected]> wrote:
>
> On Fri, Dec 18, 2020 at 08:33:37PM +0000, Jon Hunter wrote:
> >
> > On 18/12/2020 17:54, Linus Torvalds wrote:
> > > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <[email protected]> wrote:
> > >>
> > >> However, if you are saying that this is a problem/bug with our builders,
> > >> then of course we will have to get this fixed.
> > >
> > > This seems to be a package dependency problem with the gcc plugins -
> > > they clearly want libgmp, but apparently the package hasn't specified
> > > that dependency.
> > >
> > > If this turns out to be a big problem, I guess we can't simplify the
> > > plugin check after all.
> > >
> > > We historically just disabled gcc-plugins if that header didn't build,
> > > which obviously meant that it "worked" for people, but it also means
> > > that clearly the coverage can't have been as good as it could/should
> > > be.
> > >
> > > So if it's as simple as just installing the GNU multiprecision
> > > libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most
> > > debian systems), then I think that's the right thing to do. You'll get
> > > a working build again, and equally importantly, your build servers
> > > will actually do a better job of covering the different build options.
> >
> >
> > Thanks. I have reported this issue to the team that administers the
> > builders. So hopefully, they will install the necessary packages for us
> > now.
>
> Just to close the loop on this, the builders now have libgmp-dev and
> libmpc-dev packages installed and the builds are passing without the
> workaround we had used.
>
> Thierry
I was slightly concerned about your question:
"In case where CC != HOSTCC, it's possible that CC was not built against
the same version of GMP/MPC as HOSTCC. And even HOSTCC might not
necessarily have been built against the versions provided by libgmp-dev
or libmpc-dev. I'm not overly familiar with GMP/MPC, so perhaps if these
headers are reasonably stable, this is not all that important. But if it
is, then which version of GMP/MPC do we need? The version that CC was
built against, or the version that HOSTCC was built against?"
I do not have a good insight about this.
I am not sure if it is perfectly OK to
use gmp.h from HOSTCC when it was not bundled with CC.
The version difference might not be a significant issue, though...
--
Best Regards
Masahiro Yamada