Hi,
i tried to compile current torvalds tree
("78e709522d2c012cb0daad2e668506637bffb7c2") for arm/multi_v7_defconfig
and get the following build issue:
UPD include/generated/utsrelease.h
scripts/sorttable.c: In function ‘do_file’:
scripts/sorttable.c:352:7: error: ‘EM_RISCV’ undeclared (first use in
this function)
case EM_RISCV:
^
scripts/sorttable.c:352:7: note: each undeclared identifier is reported
only once for each function it appears in
I assume this is caused by:
54fed35fd3939398be292e4090b0b1c5ff2238b4 ("riscv: Enable
BUILDTIME_TABLE_SORT")
Best regards
Stefan
On Sun, 2021-09-12 at 12:29 +0200, Stefan Wahren wrote:
> Hi,
>
> i tried to compile current torvalds tree
> ("78e709522d2c012cb0daad2e668506637bffb7c2") for
> arm/multi_v7_defconfig
> and get the following build issue:
>
> UPD include/generated/utsrelease.h
> scripts/sorttable.c: In function ‘do_file’:
> scripts/sorttable.c:352:7: error: ‘EM_RISCV’ undeclared (first use in
> this function)
> case EM_RISCV:
> ^
> scripts/sorttable.c:352:7: note: each undeclared identifier is
> reported
> only once for each function it appears in
>
> I assume this is caused by:
>
> 54fed35fd3939398be292e4090b0b1c5ff2238b4 ("riscv: Enable
> BUILDTIME_TABLE_SORT")
I hit this error too. I add the follow conditional EM_RISCV
definition in sorttable.c to build pass (arm64/defconfig).
I will submit a patch out.
diff --git a/scripts/sorttable.c b/scripts/sorttable.c
index f355869c65cd..6ee4fa882919 100644
--- a/scripts/sorttable.c
+++ b/scripts/sorttable.c
@@ -54,6 +54,10 @@
#define EM_ARCV2 195
#endif
+#ifndef EM_RISCV
+#define EM_RISCV 243
+#endif
+
>
> Best regards
> Stefan
>
>
On 13/09/2021 03:49, Miles Chen wrote:
> On Sun, 2021-09-12 at 12:29 +0200, Stefan Wahren wrote:
>> Hi,
>>
>> i tried to compile current torvalds tree
>> ("78e709522d2c012cb0daad2e668506637bffb7c2") for
>> arm/multi_v7_defconfig
>> and get the following build issue:
>>
>> UPD include/generated/utsrelease.h
>> scripts/sorttable.c: In function ‘do_file’:
>> scripts/sorttable.c:352:7: error: ‘EM_RISCV’ undeclared (first use in
>> this function)
>> case EM_RISCV:
>> ^
>> scripts/sorttable.c:352:7: note: each undeclared identifier is
>> reported
>> only once for each function it appears in
>>
>> I assume this is caused by:
>>
>> 54fed35fd3939398be292e4090b0b1c5ff2238b4 ("riscv: Enable
>> BUILDTIME_TABLE_SORT")
>
> I hit this error too. I add the follow conditional EM_RISCV
> definition in sorttable.c to build pass (arm64/defconfig).
>
> I will submit a patch out.
>
> diff --git a/scripts/sorttable.c b/scripts/sorttable.c
> index f355869c65cd..6ee4fa882919 100644
> --- a/scripts/sorttable.c
> +++ b/scripts/sorttable.c
> @@ -54,6 +54,10 @@
> #define EM_ARCV2 195
> #endif
>
> +#ifndef EM_RISCV
> +#define EM_RISCV 243
> +#endif
> +
This is still broken in the mainline. Any plans to get this fix merged
there? I believe it has now been broken for nearly 2 weeks.
Thanks!
Jon
--
nvpublic
On 24/09/2021 13:15, [email protected] wrote:
> From: Jon Hunter <[email protected]>
>
>
>> This is still broken in the mainline. Any plans to get this fix merged
>> there? I believe it has now been broken for nearly 2 weeks.
>
> the fix [1] is in linux-next now, thanks.
Yes I know that. However, we need it in the mainline. It has been broken
for nearly 2 weeks now and all our automation for mainline is not
running because we cannot build. Please get this fix into mainline as
soon as possible.
Jon
--
nvpublic
On 24/09/2021 19:05, Stefan Wahren wrote:
> Hi,
>
> Am 24.09.21 um 14:55 schrieb Jon Hunter:
>>
>>
>> On 24/09/2021 13:15, [email protected] wrote:
>>> From: Jon Hunter <[email protected]>
>>>
>>>
>>>> This is still broken in the mainline. Any plans to get this fix
>>>> merged there? I believe it has now been broken for nearly 2 weeks.
>>>
>>> the fix [1] is in linux-next now, thanks.
>>
>> Yes I know that. However, we need it in the mainline. It has been
>> broken for nearly 2 weeks now and all our automation for mainline is
>> not running because we cannot build. Please get this fix into mainline
>> as soon as possible.
>
> as stated in [1], you can try to update you build environment.
These are farm build machines so not that easy or quick to update. Given
the change that introduced the breakage is in the mainline, the fix also
need to be merged into the mainline. Otherwise we need to revert the
initial change.
Jon
--
nvpublic
Hi,
Am 24.09.21 um 14:55 schrieb Jon Hunter:
>
>
> On 24/09/2021 13:15, [email protected] wrote:
>> From: Jon Hunter <[email protected]>
>>
>>
>>> This is still broken in the mainline. Any plans to get this fix
>>> merged there? I believe it has now been broken for nearly 2 weeks.
>>
>> the fix [1] is in linux-next now, thanks.
>
> Yes I know that. However, we need it in the mainline. It has been
> broken for nearly 2 weeks now and all our automation for mainline is
> not running because we cannot build. Please get this fix into mainline
> as soon as possible.
as stated in [1], you can try to update you build environment.
[1] -
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210924&id=fe7118f4742f8c26e532c63bb498283b73e24d7d
>
> Jon
>
On 9/24/21 12:01 PM, Jon Hunter wrote:
>
> On 24/09/2021 19:05, Stefan Wahren wrote:
>> Hi,
>>
>> Am 24.09.21 um 14:55 schrieb Jon Hunter:
>>>
>>>
>>> On 24/09/2021 13:15, [email protected] wrote:
>>>> From: Jon Hunter <[email protected]>
>>>>
>>>>
>>>>> This is still broken in the mainline. Any plans to get this fix
>>>>> merged there? I believe it has now been broken for nearly 2 weeks.
>>>>
>>>> the fix [1] is in linux-next now, thanks.
so who merged the patch [1] into linux-next? Andrew?
Seems to me that Andrew should be cc-ed here [added].
>>> Yes I know that. However, we need it in the mainline. It has been
>>> broken for nearly 2 weeks now and all our automation for mainline is
>>> not running because we cannot build. Please get this fix into mainline
>>> as soon as possible.
>>
>> as stated in [1], you can try to update you build environment.
>
> These are farm build machines so not that easy or quick to update. Given the change that introduced the breakage is in the mainline, the fix also need to be merged into the mainline. Otherwise we need to revert the initial change.
Yes.
--
~Randy