Hide Forgot
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.
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.
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.
Verified for build boost-1.53.0-26.el7.
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