[Starlingx-discuss] openSUSE: sm-db build failure

Qian, Bin Bin.Qian at windriver.com
Wed Sep 25 12:29:32 UTC 2019


I am wondering there is something not right in your build environment. The SmTimerIdT is defined as:
typedef int64_t SmTimerIdT;
in sm_timer.h [1] patch set 1..3, which is part of the sm-common lib. 
There are multiple printf statements in sm-common lib that use the formater "%li" such as [2], line 150, 201. I don't expect you see the same errors from sm-common build, or otherwise the sm-db won't start building as it needs sm-common.

Based on the error message in your first email, apparently the SmTimerIdT was "int" ('SmTimerIdT {aka int}'). That was the code before my commit "Enhance timer system to avoid double deregister".  [1] line 23 on the "base".

I would suggest you verify the sm_timer.h to see if it include the changes in [1], and possibly clean up your build environment to see if it helps. 
If your sm-common build also encountered the same errors, you may want to verify the size of int64_t on your build environment, it is expected to be 8-byte integer. 



[1] https://review.opendev.org/#/c/675936/3/service-mgmt/sm-common-1.0.0/src/sm_timer.h
[2] https://review.opendev.org/#/c/675936/3/service-mgmt/sm-common-1.0.0/src/sm_timer.c

From: Dominig ar Foll (Intel Open Source) [dominig.arfoll at fridu.net]
Sent: Wednesday, September 25, 2019 3:10 AM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] openSUSE: sm-db build failure

OpenSUSE is pretty strict when it comes to the quality of the code which
gets in their repo and enforce some compiler warnings to to upgraded as
There are several ways to correct those issues:

1) fix the problem in the source
The best and prefer option is to fix the code. These type errors can
induce nasty side effect and often are easy to correct.

2) change the compiler option
In the make file, select the the required option to ignore the error. If
there is no warning from the compiler, OpenSUSE will assume (rightly or
wrongly) that you know what you do and you had no choose in keeping such

3) use rpmlinrc
rpmlint calculate an ugliness marking and if you pass the threshold it
fails the package. You can change the ugliness marks allocated to
certain type of errors.
It's often easier to go around the issue, when possible (not for all
warning type) but as bad as solution 2).

It's often not longer to fix the code once for all.
That is the prefer route.


On 25/09/2019 02:55, Arce Moreno, Abraham wrote:
> Hi Bin,
> Based in our work for openSUSE [0], and due to rpmlint configuration, we are having 2 warnings treated as errors while building sm-db package:
> [    4s] sm_db_service_heartbeat.c: In function 'SmErrorT sm_db_service_heartbeat_insert(SmDbHandleT*, SmDbServiceHeartbeatT*)':
> [    4s] sm_db_service_heartbeat.c:321:13: error: format '%li' expects argument of type 'long int', but argument 35 has type 'SmTimerIdT {aka int}' [-Werror=format=]
> [    4s]                    record->heartbeat_timer_id,
> [    4s] sm_db_service_heartbeat.c: In function 'SmErrorT sm_db_service_heartbeat_update(SmDbHandleT*, SmDbServiceHeartbeatT*)':
> [    4s] sm_db_service_heartbeat.c:438:49: error: format '%li' expects argument of type 'long int', but argument 5 has type 'SmTimerIdT {aka int}' [-Werror=format=]
> [    4s]                       record->heartbeat_timer_id );
> [    4s] cc1plus: all warnings being treated as errors
> We have confirmed the package gets built after reverting commit "Enhance timer system to avoid double deregister" [1].
> Can you please guide us into the right direction to get this properly fixed?
> [0] https://review.opendev.org/#/c/679686/
> [1] https://review.opendev.org/#/c/675936/
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre

Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io

More information about the Starlingx-discuss mailing list