While rebuilding my dev-libs/boost, I noticed that it ignores my architecture of 'i486' and compiles for -march=i686 anyhow. I put '-march=i486' in my /etc/portage/make.conf CFLAGS variable, but it seems to ignore that. >>> Emerging (4 of 7) dev-libs/boost-1.62.0-r1::gentoo * boost_1_62_0.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking boost_1_62_0.tar.bz2 to /var/tmp/portage/dev-libs/boost-1.62.0-r1\ /work ... gcc.compile.c++ bin.v2/libs/atomic/build/gcc-4.9/gentoorelease/boost.locale.icu\ -off/pch-off/threading-multi/lockpool.o "i486-pc-linux-gnu-g++" -ftemplate-depth-128 -O2 -march=i486 -mtune=i486 -\ pipe -std=c++14 -finline-functions -Wno-inline -Wall -march=i686 -pthread -fPIC\ -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DN\ DEBUG -I"." -c -o "bin.v2/libs/atomic/build/gcc-4.9/gentoorelease/boost.locale\ .icu-off/pch-off/threading-multi/lockpool.o" "libs/atomic/src/lockpool.cpp"
I have figured out that I need to invoke the 'b2' build utility with an added parameter 'b2 instruction-set=i486'. I need to know how to cleanly pass 'instruction-set=i486' into the build system. Without that, it is going with a hard-coded default of i686 and it is not detecting the i486 environment.
I was able to get it to build with an inelegant patch to the boost.ebuild file: --- boost-1.62.0-r1.ebuild.orig 2017-07-17 16:42:30.623493308 +0000 +++ boost-1.62.0-r1.ebuild 2017-07-17 17:26:33.272971870 +0000 @@ -141,10 +141,11 @@ OPTIONS=( $(usex debug gentoodebug gentoorelease) "-j$(makeopts_jobs)" -q -d+2 + instruction-set=i486 ) if [[ ${CHOST} == *-darwin* ]]; then # We need to add the prefix, and in Is there a way to pass in the "instruction-set=${ARCH}" parameter to OPTIONS to the ebuild process via the command line, or perhaps adding a new USE flag?
I also just saw that problem while I compiled boost on one of my computers. On #boost@freenode somebody said that i686 is default in boost as it gives more performance. So this is an upstream problem and I wonder if/how we should handle this downstream.
I found another workaround: mkdir -p /mnt/gentoo/etc/portage/env/dev-libs/ nano -w /mnt/gentoo/etc/portage/env/dev-libs/boost - Add the following to the /mnt/gentoo/etc/portage/env/dev-libs/boost file: post_src_configure() { OPTIONS+=( instruction-set=i486 ) echo "OPTIONS updated to: ${OPTIONS[@]}" }
Does it not seem likely we could parse /etc/portage/make.conf for the CHOST variable (i486-pc-linux-gnu in this case) and make the cpu architecture available to the boost configuration files?
Created attachment 504294 [details, diff] Patch to set boost instruction-set architecture from /etc/portage/make.conf:CHOST value Here is a patch to the ebuild file that fixes this problem. It passes the boot configuration parameter "instruction-set=${MARCH}" to the configuration utility. The ${MARCH} value is obtained from /etc/portage/make.conf in the CHOST variable. It is {i486,i586,i686,x86_64}-pc-linux-gnu commonly.
This problem persists almost two years later. Can we please apply the patch I provided in comment 6 that fixes this?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7c5cac8011ada68f211a05c48150f390aa7666de commit 7c5cac8011ada68f211a05c48150f390aa7666de Author: David Seifert <soap@gentoo.org> AuthorDate: 2019-09-14 18:29:41 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2019-09-14 18:29:41 +0000 dev-util/boost-build: Version bump to 1.71.0 Bug: https://bugs.gentoo.org/624616 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: David Seifert <soap@gentoo.org> dev-util/boost-build/Manifest | 1 + dev-util/boost-build/boost-build-1.71.0.ebuild | 122 +++++++++++++++++++++ .../boost-build-1.71.0-respect-c_ld-flags.patch | 9 ++ 3 files changed, 132 insertions(+)
(In reply to tedheadster from comment #7) > This problem persists almost two years later. Can we please apply the patch > I provided in comment 6 that fixes this? I've fixed the problem differently. Removing all the default -march= tuples prevents bjam from adding them in the first place. Overriding "instruction-set" is fraught with pain, as bjam maintains its own list of valid -march= options, which is obviously idiotic and can't scale in practice (oh how I hate bjam/b2). On my Ivybridge laptop, it rejects -march=ivybridge for instance. With this fix, the user -march= value should be the final value. Please give boost 1.71 a try.
This appeared to have worked with one test compile (but on a virtual machine). Can you backport it to those of us stuck using older versions?
bjam changed a lot between 1.70 and 1.71. Given that most 1.70 bugs are fixed and 1.71 brought no API changes (unlike 1.70), I hope to stabilize boost 1.71 soon. Hence backporting these fixes won't happen, also because there's tons of bugs in 1.65 we'd like to get rid of.
Boost 1.71 is stable and old versions have been removed.
