RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1170226 - xulrunner 31 breaks spice-xpi build
Summary: xulrunner 31 breaks spice-xpi build
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xulrunner
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Martin Stransky
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1165784
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-03 14:21 UTC by Christophe Fergeau
Modified: 2015-03-06 07:36 UTC (History)
7 users (show)

Fixed In Version: xulrunner-31.4.0-1.el7_0
Doc Type: Bug Fix
Doc Text:
Clone Of: 1165784
Environment:
Last Closed: 2015-01-19 15:50:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Christophe Fergeau 2014-12-03 14:21:36 UTC
After the upgrade of xulrunner from 24 to 31 in RHEL7, spice-xpi is no longer building without some small adjustments:
- header.py and typelib.py were moved
- files including nsError.h need to be compiled with -std=gnu++1y or something like that to avoid warnings

This is easily worker around in spice-xpi, but 
+++ This bug was initially created as a clone of Bug #1165784 +++

Description of problem:
When try to build a binary from srpm, process ends with error.

Version-Release number of selected component (if applicable):
spice-xpi-2.8-7.el7

How reproducible:
Always

Steps to Reproduce:
1.get srpm and try to build binary

Actual results:
Build process ends with error:

In file included from nsScriptablePeer.cpp:54:0:
/usr/include/xulrunner-31.2.0/nsError.h:187:1: warning: identifier 'static_assert' is a keyword in C++11 [-Wc++0x-compat]
static_assert(((nsresult)0) < ((nsresult)-1),
^
In file included from nsScriptablePeer.cpp:54:0:
/usr/include/xulrunner-31.2.0/nsError.h:187:14: error: expected constructor, destructor, or type conversion before '(' token
static_assert(((nsresult)0) < ((nsresult)-1),
            ^
/usr/include/xulrunner-31.2.0/nsError.h:189:14: error: expected constructor, destructor, or type conversion before '(' token
static_assert(sizeof(nsresult) == sizeof(uint32_t),
make[5]: *** [libnsISpicec_la-nsScriptablePeer.lo] Error 1

Expected results:
build process is finished without errors and new binary is built 

Additional info:
Build process launched on TPS servers

--- Additional comment from RHEL Product and Program Management on 2014-11-19 12:27:50 EST ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Christophe Fergeau on 2014-11-20 05:48:26 EST ---

Couple of issues here. With xulrunner 31, this patch is needed (but it's not related to your problem, just dropping it here for the record):

diff --git a/SpiceXPI/src/plugin/Makefile.am b/SpiceXPI/src/plugin/Makefile.am
index 08d89d7..6ad8384 100644
--- a/SpiceXPI/src/plugin/Makefile.am
+++ b/SpiceXPI/src/plugin/Makefile.am
@@ -61,10 +61,10 @@ nsISpicec.xpt: nsISpicec.idl
 	$(AM_V_GEN)$(XPIDL) -m typelib -I $(SDK_INCLUDE_DIR) $<
 else
 nsISpicec.h: nsISpicec.idl
-	$(AM_V_GEN)$(PYTHON) `pkg-config --variable=sdkdir libxul`/sdk/bin/header.py --cachedir . -I $(SDK_INCLUDE_DIR) $< -o $@
+	$(AM_V_GEN)$(PYTHON) `pkg-config --variable=libdir libxul`/header.py --cachedir . -I $(SDK_INCLUDE_DIR) $< -o $@
 
 nsISpicec.xpt: nsISpicec.idl
-	$(AM_V_GEN)$(PYTHON) `pkg-config --variable=sdkdir libxul`/sdk/bin/typelib.py --cachedir . -I $(SDK_INCLUDE_DIR) $< -o $@
+	$(AM_V_GEN)$(PYTHON) `pkg-config --variable=libdir libxul`/typelib.py --cachedir . -I $(SDK_INCLUDE_DIR) $< -o $@
 endif
 
 BUILT_SOURCES =					\
diff --git a/configure.ac b/configure.ac
index e49e683..d251a2c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,8 +67,8 @@ AC_SUBST(XPIDL)
 
 if ! test -x "$XPIDL"; then
   AM_PATH_PYTHON
-  AC_CHECK_FILE([`pkg-config --variable=sdkdir libxul`/sdk/bin/header.py])
-  AC_CHECK_FILE([`pkg-config --variable=sdkdir libxul`/sdk/bin/typelib.py])
+  AC_CHECK_FILE([`pkg-config --variable=libdir libxul`/header.py])
+  AC_CHECK_FILE([`pkg-config --variable=libdir libxul`/typelib.py])
 fi
 
 XUL_INCLUDEDIR=`pkg-config --variable=includedir libxul`

Then you need to have -std=gnu++1y added to your CXXFLAGS to avoid the static_assert errors you mention.

Comment 4 Christophe Fergeau 2014-12-09 14:00:30 UTC
This helps with the build errors from http://download.devel.redhat.com/brewroot/work/tasks/953/8350953/build.log :
/usr/bin/python: can't open file '/usr/lib64/xulrunner-devel-31.1.0/sdk/bin/header.py': [Errno 2] No such file or directory
/usr/bin/python: can't open file '/usr/lib64/xulrunner-devel-31.1.0/sdk/bin/typelib.py': [Errno 2] No such file or directory

Adding -std=gnu++1y to the CXXFLAGS is still needed.

Comment 6 Martin Stransky 2014-12-19 14:05:58 UTC
(In reply to Christophe Fergeau from comment #4)
> Adding -std=gnu++1y to the CXXFLAGS is still needed.

Why do you need this?

Comment 7 Christophe Fergeau 2014-12-19 15:00:33 UTC
We get some errors including nsError.h without that:

In file included from nsScriptablePeer.cpp:54:0:
/usr/include/xulrunner-31.1.0/nsError.h:187:1: warning: identifier 'static_assert' is a keyword in C++11 [-Wc++0x-compat]
 static_assert(((nsresult)0) < ((nsresult)-1),
 ^
In file included from nsScriptablePeerBase.cpp:42:0:
/usr/include/xulrunner-31.1.0/nsError.h:187:1: warning: identifier 'static_assert' is a keyword in C++11 [-Wc++0x-compat]
 static_assert(((nsresult)0) < ((nsresult)-1),
 ^
/usr/include/xulrunner-31.1.0/nsError.h:187:14: error: expected constructor, destructor, or type conversion before '(' token
 static_assert(((nsresult)0) < ((nsresult)-1),
              ^
/usr/include/xulrunner-31.1.0/nsError.h:189:14: error: expected constructor, destructor, or type conversion before '(' token
 static_assert(sizeof(nsresult) == sizeof(uint32_t),
              ^
make[5]: *** [libnsISpicec_la-nsScriptablePeerBase.lo] Error 1
make[5]: *** Waiting for unfinished jobs....

Comment 9 Christophe Fergeau 2014-12-19 15:03:11 UTC
It's easy to workaround in spice-xpi btw, and we've already done so in the latest build.

Comment 10 Martin Stransky 2015-01-19 15:46:59 UTC
I wonder why do you need the -std=gnu++1y flags. 

Firefox itself is built with -std=gnu++0x (see http://download.devel.redhat.com/brewroot/packages/firefox/31.4.0/1.el7_0/data/logs/x86_64/build.log) and static_assert() is there used on many places.

Do you have specified the "-Wc++0x-compat" keyword (which seems to act here).

The static_assert macro is a part of C++0x as you can see at
https://gcc.gnu.org/gcc-4.3/cxx0x_status.html (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html)

Comment 11 Christophe Fergeau 2015-01-19 17:35:34 UTC
(In reply to Martin Stransky from comment #10)
> I wonder why do you need the -std=gnu++1y flags. 
> 
> Firefox itself is built with -std=gnu++0x

Oh I was talking about -std=gnu++1x VS not specifying any -std=xxx in the CXXFLAGS. spice-xpi used to build without any need for -std=xxx. If I use -std=gnu++0x, the build is fine as well.
> 
> Do you have specified the "-Wc++0x-compat" keyword (which seems to act here).

Yes, but it seems unrelated to the build failure (not using -Werror, and the build still fails with -Wno-c++0x-compat).
See http://download.devel.redhat.com/brewroot/work/tasks/4976/8564976/build.log for a failed build log with -Wc++0x-compat disabled. Adding -std=gnu++0x (I guess many other -std=xxx values work too) is enough to fix this.

Comment 12 Martin Stransky 2015-01-19 17:41:57 UTC
Ahh, I see. Okay, I'll add the compatibility flags there then.

Comment 15 Vladimir Benes 2015-03-06 07:36:32 UTC
This bug was verified during spice-xpi testing in house.


Note You need to log in before you can comment on or make changes to this bug.