g++ -c -pthread -Wno-invalid-offsetof -Wformat -g -DNOPCH -I/usr/include/boost-1_46 -I/usr/include/db4.8 -DUSE_SSL -fno-stack-protector -fstack-protector-all -Wstack-protector -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -march=native -O2 -MMD -o obj/nogui/checkpoints.o checkpoints.cpp
Fixed without revbump in =net-p2p/bitcoind-0.5.3 Please reopen if its still a problem.
net-p2p/bitcoind-0.5.3 doesn't/didn't call g++ directly, actually; emake does. IMO, the workaround should be reverted and this bug reassigned to whoever maintains emake.
(In reply to comment #2) > net-p2p/bitcoind-0.5.3 doesn't/didn't call g++ directly, actually; emake > does. > > IMO, the workaround should be reverted and this bug reassigned to whoever > maintains emake. emake is only make + $MAKEOPTS Please read documentation and how buildsystem work.
(In reply to comment #3) > (In reply to comment #2) > > net-p2p/bitcoind-0.5.3 doesn't/didn't call g++ directly, actually; emake > > does. > > > > IMO, the workaround should be reverted and this bug reassigned to whoever > > maintains emake. > > emake is only make + $MAKEOPTS > > Please read documentation and how buildsystem work. Well, Make is responsible for setting the correct CXX default. GNU Make apparently just does "g++"; if Gentoo wants something else, it should be done in a Gentoo-global place, not per-package...
FWIW, if CXX were set in the Portage environment, Make *would* use it...
(In reply to comment #5) > FWIW, if CXX were set in the Portage environment, Make *would* use it... I wonder why it isn't, because this actually makes sense. You'd want CXX=$(tc-getCXX) by default and hope the build system doesn't override it. In this case the build system does *not* override CXX and just inherits it from portage. So why are we getting g++ instead of $(tc-getCXX)? I'm going to reopen this and cc dev-portage@g.o to see what they think.
Well, tc-getCC is not a portage internal, it comes from toolchain-funcs.eclass, and portage can't rely on a particular eclass being available.
(In reply to comment #7) > Well, tc-getCC is not a portage internal, it comes from > toolchain-funcs.eclass, and portage can't rely on a particular eclass being > available. I know. But should we import this stuff from toolchain-funcs into portage? It seems to me that asking portage to find the compiler is not unreasonable. If you look at the number of ebuilds that do emake CC=$(tc-getCC) ... you'll see what I mean. If this were wrapped into emake (with backwards compat of course) then we'd avoid these QA problems like I hit with net-p2p/bitcoind-0.5.3. And we'd have cleaner ebuilds. Something for EAPI=5 perhaps?
Sure, just file a bug for pms-bugs@gentoo.org and make it block bug 174380.
(In reply to comment #9) > Sure, just file a bug for pms-bugs@gentoo.org and make it block bug 174380. Bug 408693 opened. Closing this one since the original issue was fixed.