[opensuse-packaging] rpmlint, or whatever checks
Hi, I never got it how to get straight forward around build failures which are caused by package checks. In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 .... I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0) Is this an rpmlint issue at all? Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11? And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier <sweet_f_a@gmx.de> writes:
It's a gcc bug.
Is it?
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 27 February 2014, Andreas Schwab wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
It's a gcc bug.
Is it?
Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp); cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 27 February 2014 15:52, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega <reddwarf@opensuse.org> wrote:
On 27 February 2014 15:52, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 27 February 2014 16:26, Andrey Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega <reddwarf@opensuse.org> wrote:
On 27 February 2014 15:52, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)?
My bad. Having gcc at my side I didn't think this through... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Cristian Morales Vega <reddwarf@opensuse.org> writes:
On 27 February 2014 15:52, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Is it valid C code?
I think yes: v->rvsn = hextou(++bp, &bp);
It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.
There is a sequence point before the function call. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Feb 27, 2014 at 7:52 PM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Thursday 27 February 2014, Andreas Schwab wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
It's a gcc bug.
Is it?
Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html
And it's just a gcc warning not an error.
It's a potentially serious warning. Don't ignore it.
No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.
Is adding pragma around this code an option? I do not have example ready right now, but would be something like
I mean it should be possible to build an rpm from valid C code right?
Is it valid C code?
I think yes:
#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wsequence-point"
v->rvsn = hextou(++bp, &bp);
#pragma GCC diagnostic pop -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier <sweet_f_a@gmx.de> writes:
v->rvsn = hextou(++bp, &bp);
What is hextou? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le Thursday 27 February 2014 à 17:25 +0100, Andreas Schwab a écrit :
Ruediger Meier <sweet_f_a@gmx.de> writes:
v->rvsn = hextou(++bp, &bp);
What is hextou?
Some kind of curse probably, beware! -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 02/27/2014 04:52 PM, Ruediger Meier wrote:
v->rvsn = hextou(++bp, &bp);
At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 27/02/14 13:33, Bernhard Voelker escribió:
On 02/27/2014 04:52 PM, Ruediger Meier wrote:
v->rvsn = hextou(++bp, &bp);
At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement.
Also, ++bp may be evaluated more than once in the case of a macro.. and that's extremely difficult to debug. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?
Can you point me to your source code / project/package in OBS, then I can check this? gcc is usually right for this warning.
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?
- suppress the gcc warning - #!BuildIgnore post-build-checks I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Marcus Meissner <meissner@suse.de> writes:
- #!BuildIgnore post-build-checks
This is too big of a hammer. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:
On Thursday 27 February 2014, Marcus Meissner wrote:
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
Fix the original bug and do not work around it.
That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?
Can you point me to your source code / project/package in OBS, then I can check this?
gcc is usually right for this warning.
See my other email in this thread in reply to Andreas. The complete source is in home:rudi_m:devel-snap/dateutils dateutils-0.2.7.git*.tar.xz [ 97s] build-aux/yuck-scmver.c: In function 'git_version': [ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?
- suppress the gcc warning
Ok thanks, I do this now because it has minimal impact: ... # work around false positive post-build-checks %if 0%{?sles_version} export CFLAGS="$RPM_OPT_FLAGS -Wno-sequence-point" %endif ... But it looks really ugly within spec file. I was hoping I could hide this in rpmlinrc or wherever.
- #!BuildIgnore post-build-checks
I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format.
Maybe this is something which needs to be fixed for SLE_11. I have already ugly lines in the spec file because it does not understand this rpmlintrc: ... # rpmlint complains about our release tarballs in / addFilter(".*-release-tarball.* suse-filelist-forbidden-fhs23 /release_obs_.*") ... while this works for all other distros. Actually it looks like SLE does not understand rpmlintrc at all. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 27 February 2014 16:36, Andreas Schwab <schwab@suse.de> wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Cristian Morales Vega <reddwarf@opensuse.org> writes:
On 27 February 2014 16:36, Andreas Schwab <schwab@suse.de> wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
It was just a guess, since hextou is a static function. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab <schwab@suse.de> wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries. The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Thu, 27 Feb 2014, Ruediger Meier wrote:
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab <schwab@suse.de> wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
The link you posted doesn't indicate a gcc bug, Diego was confused, it used macros, not function calls and amounted basically to *c++ = *c; and _that_ does correctly cause a warning (there really is no sequence point between lhs and rhs of assignments). Your case is different, there you had hextou(++bp, &bp); And now comes the guesses: probably hextou (a static function, not macro) uses the value of *arg2 (i.e. bp), as well as the incremented value. With a little inlining and depending on how hextou's code looks like, that can very well result in effectively the same code as the invalid one above. But as there's a sequence point right before calling the function, there actually is no problem, also not after inlining. So your case does show a gcc bug (in not properly maintaining sequence point rules over inlining, as Andreas said), the link you posted does not. Now, of course, nothing of that helps you in your problem, but perhaps is entertaining :) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 27 February 2014, Michael Matz wrote:
Hi,
On Thu, 27 Feb 2014, Ruediger Meier wrote:
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab <schwab@suse.de> wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
The link you posted doesn't indicate a gcc bug,
I just thought they are going to bug report this http://gcc.gnu.org/ml/gcc-help/2008-02/msg00320.html cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier <sweet_f_a@gmx.de> Thu, 27 Feb 2014 18:29:11 +0300:
Hi,
I never got it how to get straight forward around build failures which are caused by package checks.
In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....
I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.
cu, Rudi
rpm -qf /usr/lib/build/checks-data/check_gcc_output
Hello. It is a post build check: https://en.opensuse.org/openSUSE:Packaging_checks#post-build-checks_and_brp-... post-build-checks-1.0-119.1.2.noarch -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (10)
-
Andreas Schwab -
Andrey Borzenkov -
Bernhard Voelker -
Cristian Morales Vega -
Cristian Rodríguez -
Dmitriy Perlow -
Jean Delvare -
Marcus Meissner -
Michael Matz -
Ruediger Meier