On 13.08.21 15:17, Fabrice Fontaine wrote:
> Le ven. 13 août 2021 à 10:54, Jan Kiszka <jan.kis...@siemens.com> a écrit :
>>
>> On 13.08.21 10:12, Fabrice Fontaine via Xenomai wrote:
>>> Allow the user to disable demo and testsuite to avoid the following
>>> build failures on arc and riscv32:
>>
>> Are you working on ports to those archs? Or is xenomai userland just
>> prematurely built for those in buildroot?
> No, I'm not working on ports to those archs. I just sent this patch to
> fix buidlroot autobuilder failures. I'm not even an expert in xenomai.
> In buildroot, we allow to build xenomai userland on all architectures.
> The only requirement on the toolchain is that it must have threads,
> sync and must be uclibc or glibc:
> https://git.buildroot.net/buildroot/commit/package/xenomai/Config.in?id=c35f157486431eafdb8d3583fc52d8ce4c784cf3.
> In cobalt core, we're restricting the architectures to x86, powerpc and ARM.
Ah, ok, these are mercury userland builds. Makes more sense now.
>>
>>>
>>> latency.c: In function 'display':
>>> latency.c:326:21: error: format '%ld' expects argument of type 'long int',
>>> but argument 2 has type 'time_t' {aka 'long long int'} [-Werror=format=]
>>> 326 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
>>> | ~~~~^
>>> | |
>>> | long int
>>> | %.2lld
>>> 327 | "priority %d)\n", dt / 3600,
>>> | ~~~~~~~~~
>>> | |
>>> | time_t {aka long long int}
>>>
>>> altency.c: In function ‘display’:
>>> altency.c:262:21: error: format ‘%ld’ expects argument of type ‘long int’,
>>> but argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
>>> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
>>> | ~~~~^
>>> | |
>>> | long int
>>> | %.2lld
>>> 263 | "priority %d)\n", dt / 3600,
>>> | ~~~~~~~~~
>>> | |
>>> | time_t {aka long long int}
>>>
>>
>> How about fixing those issues instead?
> Indeed, fixing those issues would be great. I'll let you handle that.
I wouldn't mind getting patches as well. ;)
> However, I also think that disabling demo and testsuite is a nice
> addition as it will decrease compile time and save disk space.
I don't disagree. I just don't like merging a feature with the argument
"this works around a bug". If you resend with adjusted reasoning, I'm
fine with merging the functional changes.
But then I would still not use that to address the above errors...
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
