Got a %endif with no %if

Bug #1058378 reported by AndreyUA
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
rpm (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Ubuntu 12.10 beta2
rpm 4.10

When compiling this spec

Summary: GNU Compiler Collection
Name:% {_stm_pkg_prefix}-cross-gcc
% if_target_cpu sh
Version: 4.5.2
% else
% if_target_cpu arm
Version: 4.5.0
% else
Version: 4.2.4
% endif
% endif
Release: 78
License: GPL / LGPL
Group: Development / Languages

Compilation stops with an error

Got a% endif with no% if

With version 4.9.9 compiles ok.

Revision history for this message
AndreyUA (andrey-wys) wrote :

Sorry, rpm 4.9.1.1 compiles ok.

Revision history for this message
Mike Miller (mtmiller) wrote :

The macros %_stm_pkg_prefix and %if_target_cpu are not standard in rpm, this can't be reproduced without a definition of at least %if_target_cpu. Can you attach whatever custom rpm macro files you have as well as the full spec file you are compiling?

Or switch to using a more standard approach using the built-in %ifarch statement.

Revision history for this message
AndreyUA (andrey-wys) wrote :

I'm trying to build this project http://dev.duckbox.info/

The error occurs when compile this file:
ftp://ftp.stlinux.com/pub/stlinux/2.4/updates/SRPMS/stlinux24-cross-gcc-4.5.2-78.src.rpm

Revision history for this message
Mike Miller (mtmiller) wrote :

You must have a custom RPM configuration that I don't have, either in /etc/rpm or ~/.rpmmacros, to define %if_target_cpu. Here's what I get attempting to build this package on Ubuntu 12.04:

mike@precise:~$ rpm --version
RPM version 4.9.1.1
mike@precise:~$ rpmbuild -bb rpmbuild/SPECS/stm-cross-gcc.spec
error: parse error in expression
error: /home/mike/rpmbuild/SPECS/stm-cross-gcc.spec:3: parseExpressionBoolean returns -1

and on Ubuntu 12.10 beta:

mike@quantal:~$ rpm --version
RPM version 4.10.0
mike@quantal:~$ rpmbuild -bb rpmbuild/SPECS/stm-cross-gcc.spec
error: line 3: Unknown tag: %if_target_cpu sh

What do you get from running "rpm --eval %if_target_cpu"?

Revision history for this message
AndreyUA (andrey-wys) wrote :

This is folder rpm from tdt duckdox
http://www.mediafire.com/?wk2yxmhr0wc34jp

Revision history for this message
Mike Miller (mtmiller) wrote :

Ok, I'm able to reproduce this now. Attached is a smaller spec file that shows the same problem like so:

$ rpmbuild -bb --target=x86_64-linux lp-1058378.spec
builds fine
$ rpmbuild -bb --target=i386-linux lp-1058378.spec
error: /home/mike/lp-1058378.spec:19: Got a %endif with no %if

I think the problem is that macros are now not expanded in the false condition of an if-else, so the second %if_target_cpu is not expanded and the parser sees an extra %endif. This is an issue with rpm upstream, also fails for me in Fedora 18 alpha. I can ask about this upstream to see if this behavior is intentional or a bug.

Changed in rpm (Ubuntu):
status: New → Confirmed
Revision history for this message
AndreyUA (andrey-wys) wrote :

Thanks for your help.

Revision history for this message
Mike Miller (mtmiller) wrote :

I posed this problem to the rpm devs, here is the result of the discussion.

http://lists.rpm.org/pipermail/rpm-list/2012-October/001273.html

I tend to agree with their assessment that this is a fix worth keeping and not a bug. I recommend that you submit a bug report to STLinux at https://bugzilla.stlinux.com/ to adapt their rpm configuration to work with rpm >= 4.10.

This error is specific to the way their rpms are constructed and is more or less easily worked around. It is something that STLinux is going to have to deal with sooner or later as rpm 4.10 starts to go out with the latest release of Fedora and other distributions. Let me know if you need help reporting the problem to them or any other support.

Revision history for this message
Mike Miller (mtmiller) wrote :

Marking invalid since this change was intentional according to upstream.

Changed in rpm (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.