Bug 1305019

Summary: boost-build gcc.jam file no longer translates compile options such as O3 and -g for release and debug builds with the GCC/G++ toolset specifically (the default toolset)
Product: Red Hat Enterprise Linux 7 Reporter: Matt <matt>
Component: boostAssignee: Jonathan Wakely <jwakely>
Status: CLOSED ERRATA QA Contact: Miloš Prchlík <mprchlik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.4CC: mcermak, mnewsome, mprchlik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Feature: The gcc.jam file installed by the boost-build package now defines useful default compilation options. Reason: The Red Hat Enterprise Linux packaging system provides its own compilation options when building the Boost packages, but other programs built with Boost.Build may want to use the default options for the toolset. Result: It should no longer be necessary to override build flags when compiling with Boost.Build's gcc toolset.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 06:33:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt 2016-02-05 10:52:25 UTC
Description of problem:
Boost-build

Version-Release number of selected component (if applicable):
boost-build-1.53.0-25.el7.noarch

How reproducible:
100% / fairly trivial

Steps to Reproduce:
1. Try to build a project with Jamroot having an element such as <debug-symbols>on
2. Run bjam -d2 (for debug level 2) release install and see if your c++ option of "-g" for debug-symbols gets passed through. (it does not - it does for the linking part but not the compiling options)
3. As a further step -- see if your program's core dump has line numbers (-g would do this).  It does not have line numbers.

Actual results:

Default options for a "bjam release install" or "bjam debug install" no longer translate typical macros appropriately from a project's Jamroot such as "-g" for <debug-symbols>on or "-O3" for <optimization>speed.  

I traced it down to the file /usr/share/boost-build/tools/gcc.jam appearing to have left out several key elements that were in previous versions of boost-build packages gcc.jam files such as the following lines in gcc.jam that are no longer present:

> toolset.flags gcc.compile OPTIONS <optimization>off   : -O0 ;
> toolset.flags gcc.compile OPTIONS <optimization>speed : -O3 ;
> toolset.flags gcc.compile OPTIONS <optimization>space : -Os ;
>
> toolset.flags gcc.compile OPTIONS <inlining>off  : -fno-inline ;
> toolset.flags gcc.compile OPTIONS <inlining>on   : -Wno-inline ;
> toolset.flags gcc.compile OPTIONS <inlining>full : -finline-functions -Wno-inline ;
>
> toolset.flags gcc.compile OPTIONS <warnings>off : -w ;
> toolset.flags gcc.compile OPTIONS <warnings>on  : -Wall ;
> toolset.flags gcc.compile OPTIONS <warnings>all : -Wall -pedantic ;
> toolset.flags gcc.compile OPTIONS <warnings-as-errors>on : -Werror ;
>
> toolset.flags gcc.compile OPTIONS <debug-symbols>on : -g ;
> toolset.flags gcc.compile OPTIONS <profiling>on : -pg ;
> toolset.flags gcc.compile OPTIONS <rtti>off : -fno-rtti ;

Additional info:

Normally perhaps I'd say this is a feature rather than a bug whereby the boost-build package maintainer expects you to use a different macro than previous versions.  But I'm pretty sure it is a bug because of a few things:

1) Almost all the other tools .jam files still have those macro translations spelled out such as the following non-gcc/non-g++ toolsets:

/usr/share/boost-build/tools/clang-darwin.jam:toolset.flags clang-darwin.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/clang-linux.jam:toolset.flags clang-linux.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/como-linux.jam:flags como-linux CFLAGS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/cray.jam:flags cray.compile OPTIONS <optimization>speed : -O3 ;
/usr/share/boost-build/tools/gcc.py:flags('gcc.compile', 'OPTIONS', ['<optimization>speed'], ['-O3'])

2) Even the gcc.py file (/usr/share/boost-build/tools/gcc.py) still has -O3 translation:

/usr/share/boost-build/tools/gcc.py:flags('gcc.compile', 'OPTIONS', ['<optimization>speed'], ['-O3'])

3) The default boost-build still uses macros like <optimization>speed for release.  Why would the macro be present if it wasn't expected to be translated to a real-world configuration flag like "-O3".

4) Although I noticed this problem when upgrading from a (very old) version of boost, it appears that the newest version of boost does have those macro translations re added again to the gcc.jam file.  (see https://github.com/boostorg/build)  However that newer version appears quite a bit ahead of both the current RHEL7 and the previous super old version I used to use.  So perhaps it is better to specifically patch gcc.jam based on an older working version vs the newest/latest in case something breaks.  (a diff of my old version and the current RHEL7 version only reveals a few minor changes including those macro expansions vs a diff of the latest greatest reveals quite a number of changes)

Possible Solution To Bug:

Please add back in such toolset.flags options in the gcc.jam file.  For now we have to manually add stuff like "<variant>release:<cxxflags>-O3" which is likely not the intention of the boost-build package maintainers.

Comment 2 Matt 2016-02-08 15:01:14 UTC
Just worth noting a key element that make this case worth solving:

This happens for the default "bjam release install" and "bjam debug install" build options on the most popular gcc and g++ compilers.   That is, "bjam release install" is meant to turn inlining and optimizations on.  Similarly "bjam debug install" is meant to turn debugging on.  Neither works because of these missing entries in the gcc.jam file.

In other words, this isn't an unusual task.  The vast majority of folks running the boost build commands will not get the proper compiler options for a given variant such as the two most default entries common (debug and release).

We had a production issue and were expecting line numbers in the core dump because we thought "-g" would have been passed through but it was not.  Rather unfortunate bug when moving from RHEL6 to RHEL7.

Comment 3 Jonathan Wakely 2016-02-08 15:13:05 UTC
The flags are removed from gcc.jam as a result of the patch for https://bugzilla.redhat.com/show_bug.cgi?id=1070789 (see comment 2).

If I understand correctly, that was done to ensure that the boost libraries themselves are built as intended for RHEL. I think the fact that the flags are also absent when you use that gcc.jam file to build your own software is unintentional, but I'm still investigating.

Comment 7 Miloš Prchlík 2016-07-04 08:36:42 UTC
Verified for build boost-1.53.0-26.el7.

Comment 9 errata-xmlrpc 2016-11-04 06:33:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2442.html