Bug 408481 – portage should set CC=$(tc-getCC) and CXX=$(tc-getCXX) by default: was net-p2p/bitcoind-0.5.3 calls g++ directly

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Agostino Sarubbo 2012-03-16 09:12:10 UTC]

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

[Comment 1 Anthony Basile 2012-03-16 12:27:37 UTC]

Fixed without revbump in =net-p2p/bitcoind-0.5.3

Please reopen if its still a problem.

[Comment 2 Luke-Jr 2012-03-16 13:06:08 UTC]

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.

[Comment 3 Agostino Sarubbo 2012-03-16 15:22:47 UTC]

(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.

[Comment 4 Luke-Jr 2012-03-17 22:52:48 UTC]

(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...

[Comment 5 Luke-Jr 2012-03-17 22:57:19 UTC]

FWIW, if CXX were set in the Portage environment, Make *would* use it...

[Comment 6 Anthony Basile 2012-03-18 00:31:04 UTC]

(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.

[Comment 7 Zac Medico 2012-03-18 00:35:59 UTC]

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.

[Comment 8 Anthony Basile 2012-03-18 00:51:56 UTC]

(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?

[Comment 9 Zac Medico 2012-03-18 01:17:12 UTC]

Sure, just file a bug for [e-mail] and make it block bug 174380.

[Comment 10 Anthony Basile 2012-03-18 10:40:21 UTC]

(In reply to comment #9)
> Sure, just file a bug for [e-mail] and make it block bug 174380.

Bug 408693 opened.  Closing this one since the original issue was fixed.